Project Spaces and Logical Divisions of Vocabularies

[John McCloud]

Hello VocBench Users + Devs,

I have a (potentially sophomoric) question that I have not seen elsewhere about the way we logically might divide our controlled vocabularies within VocBench. 

I recognize that a project space allows us to logically group together things like thesauri as well as authority lists as multiple skos concept schemes under a single project, and I appreciate that. However, I keep wondering about other constructions in other contextual spaces that might overlap. What I'm looking for is the criteria by which one says "no no, this goes into another project space" and/or "well, this is just another vocabulary under the same project space." It's a bit subjective, to be sure *unless there are technical reasons why one would choose to divide one way vs another; I can think of one possibility here), but an example:

Consider a situation where you are dealing with media. Any kind of media. And you have a hierarchical vocabulary that sets the broad structure of the media of interest and its bits and bobs. You have creators in here as people who create the media, sub-types of media, etc. You also have authority lists in here that set lists of media companies, record labels, etc.

Well, now say you also had movies and books projects in vocbench as their own projects. Don't those projects fall under "media," broadly and want for mapping between "author" (of a book) and "creator" (of media), etc?

Is it that you should combine those other projects into one project space as a general "media" with linked concept schemes of books, movies, music, etc. or should they remain separate as their own project spaces? 

Does VocBench's model with project spaces and multiple, share-able concept schemes nudge us to consider one solution as more favorable than another?

Thanks,

-John

[John Gomersall]

Hi John,

I'm not massively experienced with RDF vocabularies but from what I have seen so far it is very similar to the organisational problems faced in software engineering.

My experience with that is to structure projects around the communities that maintain and consume them. In simple terms, if a project is too big then too many diverse people will be editing different parts of it at different times, causing "merge conflicts", whereas if things are too small then you potentially have to edit may projects to achieve a relatively simple objective.

In your media example I would suggest that people who consume and maintain information about books are different from those dealing with the music industry (in a professional sense).

Hope that helps.

Regards

John

[stel...@uniroma2.it]

Dear John,

 

By first, thanks to John Gomersall for picking this up. I was o holiday first, and I’m now teaching in a summer school, so will be mostly off list for a few days more.

 

In addition to what John properly said, I won’t give a single rule of thumb, but a few considerations:

 

1. A basic mechanism that would apply – in absence of other considerations or constraints – is: one dataset one project. If you have something that you plan to release as an independent dataset, under a single sparql endpoint, possibly with a single URI space, put everything on a single project and then, if you want to keep some separation to the purpose of organizing and coordinating the dataset’s maintenance, you can do internally, with named graphs (it is now possible in VB3 to switch the namedgraph, to associate different URIs with different named graphs etc..), with concept schemes (if a SKOS resource) and so on and so forth with diverse solutions
   About schemes, considering that VocBench also allows to restrict the permissions of users to concepts and resources belonging only to certain schemes, see: https://vocbench.uniroma2.it/doc/tipsntricks/multischememultitaxonomy.jsf
   So, it is perfectly normal to have a single dataset (and a single project for modeling it) with several concept schemes and, possibly, separated permissions
   
   
2. Pls consider that, with some (manageable) complications added, one-to-many or many-to-one solutions are also possible: the multigraph management can be also used to export each graph as a different dataset, while keeping all of them on the same project, possibly controlling very closely the amount of overlap (i.e. matchable concepts) between the different datasets; conversely, a merge of content from different projects can be easily done (it’s one of the big advantages of using triples!) even though I rarely see the need to split a single, homogeneous,  dataset as different projects

 

3. However, a question in turn might be – in lack of other constraints in turn, which can also be political! – whether it is the case to see certain “content” as separate datasets or as a single one (and then the mapping to projects is another matter)
   In deciding whether two “portions” of content deserve to be in the same dataset or no, you might consider how much a portion is an appendix of/is functional to the data of some other portion. Same as in OO design, if something doesn’t deserve to be a re-usable piece of software/content, then it can be “hidden” (encapsulation) into some other stuff. If two “portions”, instead, make sense as independent reference models/datasets, then it’s better to keep them as different datasets. E.g. if a description of mediatypes would not just be a partial perspective on the domain useful only to describe certain resources, but a very relevant resource per se, better to have it separated, and owl:imported into the other dataset describing resources (e.g. books).

 

Hope it helps!

 

Cheers,

 

Armando

 

Da: vocben...@googlegroups.com <vocben...@googlegroups.com> Per conto di John McCloud
Inviato: sabato 15 agosto 2026 01:25
A: vocbench-user <vocben...@googlegroups.com>
Oggetto: [vocbench-user] Project Spaces and Logical Divisions of Vocabularies

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/1eac14ee-767d-4e71-9548-c086976c34b6n%40googlegroups.com.