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