Re: ISSUE-160: Allowing collections in semantic relationships

Hi Aida,

> 
>> To pick a concrete example, in a previous mail you said that node 
>> labels from ISO-25964 were actually not entirely captured by 
>> skos:Collection. OK, but then if we follow this path, we have to add 
>> another class to our model, and maybe a couple of additional 
>> properties. This would make the SKOS model more complex, for dealing 
>> situations which I believe are not that common (at least compared to 
>> the variety of KOSs outside there), and therefore could turn to be 
>> counter-productive.
> 
> It would be very important that you explain why is complexity counter 
> productive in the case of SKOS. Who are intended SKOS users?

People who have been told that they do not need the full complexity of OWL construct and spend months learning it and using to model the huge bodies of knowledge they already have.

Maybe for *you* who are accustomed to these levels of complexity, there is no problem. But for less expert people it makes a huge difference whether you have 20 constructs in your model or 30, and when the differences between them become more difficult to grasp...
And actually looking at Leonard's ISO model I realize that there is much more than 10 constructs to add to SKOS to be fully compatible with ISO-25964.


> 
>  From the point of view of interoperability it may be better (cheaper 
> and easier) if people have to simplify a complex format than if we all 
> have to extend dumbed down formats. If more classes are needed by an 
> entire community of users then it is far better that these classes are 
> added by SKOS developers than by users.
> Standards have also power of introducing and instructing about a good 
> practice.

I'm really not sure about this. Dublin Core has proven to be an immense help for exchange of information, even if its users are often accusing it of incompleteness or fuzziness.
Would the result have been the same if the proposed standard had been close to MARC?

Further, there is the philosophy of the semantic web, which claim that a set of minimal vocabularies that extend each other, if reasonable to achieve, is more desirable than all-encompassing, complex things. Semantc web makes it *really* easy to extend models and still being *fully* compatible with them.

So I think SKOS is oriented towards being used in combination with "application profiles", such as the SKOS-XL we've proposed.

> 
> So far SKOS is not created to port any of existed structured vocabulary 
> in its completeness and for each of existing vocabularies there would be 
> need to make extensions in order to prevent data loss. Thesaurus, having 
> a simplest structure, is the one that seems to be the closest to be 
> fully supported by SKOS. I see many advantages in having at least one 
> type of vocabulary for which there is no need to develop extensions.

It seems difficult to disagree with that.
But there are also many disadvantages. The complexity, as I mentioned, but also more strategical aspects. E.g. if we just duplicate ISO-25964 then it's more difficult for a user to see the differences between the two. And people with no thorough experience in KOS design would just think that SKOS is yet another thesaurus standard, maybe not fitting their specific need...

Cheers,

Antoine

Received on Tuesday, 16 December 2008 09:21:19 UTC