Re: ISSUE-160: Allowing collections in semantic relationships

Hi Leonard,

>>
> Treating node labels as concepts is not just "not a best practice" - it 
> is logically wrong and misleading.
> 
> If SKOS is just to be used for the generation of hierarchical displays 
> then this fudge can be used, but I thought that it was more than that 
> and was concerned with the accurate representation of semantic 
> relationships - witness the extended discussion of the distinction 
> between "broader" and "broader transitive", for example.

That's one of the problems of the scope of SKOS. Indeed, for most applications one can say (and I would follow you here) that treating node labels as concepts was logically wrong. But for some others, well, I'd say it depends on the target the KOS designer has in mind. 

> 
> Doing it properly may be slightly more complicated, but that is because 
> the semantic relationships are more complicated. I don't think you can 
> ignore them. If you just want to generate displays you don't need SKOS 
> at all, you can just use simple tags like BT/NT/RT, which give a much 
> simpler exchange format that has served us well in many applications up 
> to now.

I agree, and disagree at the same time :-) 
On the semantic web, there is no semantic BT/NT/RT language available. I believe that it is indeed in the SKOS mission to play that role.
If we start defending positions such as: "SKOS do represent links like BT/RT/NT, as they appear in BS-8723/ISO-25964, but wait a minute, they are not the same as the simpler ones that you would want to use in your hierarchy", then I think we're in trouble wrt. to our "Simple" aspect. I think SKOS should capture more than thesaurus alone.

> 
> I'm also concerned that you say that a more complete representation is 
> "maybe also too much BS-8723 oriented". Is that a bad thing? In fact it 
> would be better if it were more ISO 25964 oriented, following the model 
> attached to my message of 4th December, which is a later development of 
> the BS-8723 model and which makes the important distinction between 
> "arrays" and "concept groups".
> 
> I am really keen that if SKOS is to become a de facto standard for the 
> exchange of thesaurus data it should be capable of modelling all the 
> elements of a modern thesaurus that complies with standards. If you 
> don't like our model, please tell us what is wrong with it; if you do, 
> why not use it?

Please don't get me wrong here, Leonard!
BS-8723/ISO-25964 has played a huge role in the design of SKOS, and I believe it will still be. Yet I do believe that we cannot and should not capture everything from it.

My concern is actually that SKOS, contrary to what you hint, is not *essentially* aimed at to become a standard for the flawless exchange of thesaurus data. SKOS owes much to thesaurus standards, and indeed most of its model is inspired by them, which makes it appropriate to exhange a great deal of thesaurus information. However, it should not pay the price of a too high complexity ("modelling all the elements of a modern thesaurus that complies with standards") to fulfil that mission. There is a danger of "overfitting" there, which may prevent the application of SKOS to other kinds of KOSs.

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.

To sum up, I expect that SKOS will be used for conveying some (indeed, most) thesaurus information, but in some cases it should be completed by appropriate extensions. Or in other words, SKOS is not a simple porting of BS-8723/ISO-25964 on the semantic web. Which makes actually our missions clearer, when you think about it. In your team I trust that you have enough talented people for which it wouldn't be a problem to create a Semantic Web representation of your model, making SKOS completely redundant.
In that respect I consider that Johan' solution is interesting. He represents node labels (in a very similar way as you do, by the way), but as an extension to SKOS...

Am I making sense? I admit have great difficulties to express my thoughts on this subject, and apologize for it.
Feedback is of course still welcome, Leonard :-)

Best,

Antoine

Received on Tuesday, 16 December 2008 00:48:18 UTC