[SKOS] About ISSUE-36, ISSUE-39, ISSUE-44, (was Re: [SKOS] central issues)

Hi Bernard,

[Changing the subject hoping our issue tracker will automatically attach 
the mails to the corresponding issue pages]

>>> Is the following allowed if ex:schemeA and ex:schemeB are different?
>>>
>>> ex:foo  skos:inScheme  ex:schemeA
>>> ex:bar  skos:inScheme  ex:schemeB
>>> ex:foo  skos:narrower ex:bar
>> Is this different from the example I gave in [1] , of which I 
>> copy-paste a sample below?
>>> ex1:platypus skos:broader ex2:eggLayingAnimals.
> Let me put it in a more formal way.
> No, indeed! But that example is lost in the midlle of mapping 
> relations  ... so I missed it.
> Actually I wonder why this assertion is in this example. I find it 
> rather confusing, since it is the only broader-narrower ...

Well the idea was to produce one example. I could have overloaded the 
picture, but then the whole proposal would have been really long...
We are reaching the limits of what is possible for a technical document 
that is designed primarily for the SWD working group, not a primer :-(
But of course it is useful to get advice from outside :-)

>>
>> and is the following sentence from [1] not ok as well?
>>
>>> allowing skos:broader statements to hold between concepts from 
>>> different concept schemes
> I understand - but I'm not sure I agree :-) . Is not keeping the 
> relationships broader-narrower contained inside a Concept Scheme safer 
> for implementations?

You could be right, but I can also see reasons for using broader between 
different CS:
- the semantic information carried by the link is the pretty much the 
same in both situations
- at some point we should assume that one of the objectives of SKOS is 
to enable the sharing and reuse of vocabularies, in a real 'semantic 
web' fashion (think of the way rdfs:subClassOf works). A typical case 
the I import a scheme from another place, and creation of local 
extensions for it. Would I really like to use a different property?
Finally, if you are on a semantic web of vocabularies, you can still 
restrict yourself to query for broader statements in a single concept 
scheme by just adding inScheme-conditions on your concepts. It is more 
effort, sure, but I'm not convinced this is an horrible burden :-)

>>>>>    * If a concept belongs to several concept schemes, would it be 
>>>>> possible / does it make sense to distinguish broader-narrower 
>>>>> hierarchies in different schemes?
>>>>
>>>> I think this is covered by ISSUE-36 ConceptSchemeContainment 
>>>> http://www.w3.org/2006/07/SWD/track/issues/36
>>> Well, it's related, but not exactly covered. The original question 
>>> of Sean is not exactly that one, it aks how to assert the 
>>> containment of a relationship in a ConceptScheme. Mine is to know if 
>>> an assertion using broader-narrower has to be contained in a 
>>> ConceptScheme at all; Or, it implies that the above situation is 
>>> clarified to begin with. Granted, it's not strictly forbidden, but 
>>> one would think that "a consistent set of concepts" implies that 
>>> broader-narrower are internal. This is what one can understand by 
>>> "consistent" e.g., a thesaurus which is migrated to SKOS. 
>>> Broader-narrower are internal to the Thesaurus.
>>>
>>
>> OK, you question is more "should it be contained in a specific CS" 
>> rather than "if we want ot have it contained in a CS, how should we 
>> do it", which is the way issue-36 is now written.
> Exactly.
>>
>>>>> Related question, I would like to see specified the semantics of 
>>>>> ConceptScheme, and the difference between ConceptScheme and 
>>>>> subclass of Concept.
>>>> ???
>>> OK. It was late last night when I wrote this. There agian, let me be 
>>> more formal.
>>> What are the differences, both semantic and functional, between the 
>>> following modeling choices?
>>>
>>> ex:bar      rdf:type      skos:ConceptScheme
>>> ex: foo  skos:inScheme   ex:bar
>>>
>>> vs
>>>
>>> ex:bar       rdfs:subClassOf      skos:Concept
>>> ex: foo  rdf:type   ex:bar
>>>
>>> IOW, in which cases do I need a Concept Scheme rather than a 
>>> subclass of skos:Concept. This is one of the most obscure points of 
>>> the current spec, as far as I am concerned.
>>>
>>> Is it clearer now?
>>
>> Yes. If I understand well you wonder wether it is proper to model 
>> concept scheme membership by means of using the 
>> ConceptScheme/inScheme apparatus, or by means of dedicated subclassed 
>> of Concept (ex:ConceptFromBarConceptScheme, to make the name in your 
>> example more explicit?)
>>
>> I would say that both are possible, but I would not favor a pure 
>> 'sub-class of Concept' option. If you don't use the Concept/inScheme 
>> properties at all, then the scheme membership information is not 
>> formally  represented in your data, and you cannot benefit from all 
>> the nice semantics we could propose for situations where concept 
>> scheme membership is known (e.g. constraints on prefLabel)
> It is all those "nice semantics" that should be explicited! What can I 
> do with a skos:inScheme declaration that I cannot do with a rdf:type? 
> Just wondering. Have you examples in mind?

Well consider the case where we forbid two concepts from a same concept 
scheme to have a same prefLabel. To test this we need the info that two 
concepts are in a same concept scheme, right?
Now would I access such information with the rdf:type info? The only way 
to represent CS membership would be to create a specific kind of 
Concept, say ConceptFromMyCS. One could imagine a condition like "if two 
concepts are instances of the same subclass of skos:Concept and have the 
same prefLabel, we have a problem".

But now, imagine that I want to create another subclass of skos:Concept 
to represent something completely different from CS membership, which is 
completely legal, e.g. ConceptCreatedByMe. Nothing could prevent two 
concepts created by me to have the same label (if they in fact belong to 
different CS). So you could have false trigerring of the rule above.

Therefore we need explicit CS membership info. It is possible to 
implicitly represent CS membership by your subclass trick, but the 
problem is that the subclass pattern can be used for completely 
different matters, and hence cannot be the basis for sound constraint 
specification.

Antoine

Received on Thursday, 28 June 2007 07:46:25 UTC