W3C home > Mailing lists > Public > public-esw-thes@w3.org > June 2007

Re: [SKOS] central issues

From: Bernard Vatant <bernard.vatant@mondeca.com>
Date: Wed, 27 Jun 2007 17:56:55 +0200
Message-ID: <468288C7.9040409@mondeca.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: SWD WG <public-swd-wg@w3.org>, public-esw-thes@w3.org

Antoine

Thanks for leading me into more detailed reading. Oops. I missed small 
prints :-[
>> Let me put it in a more formal way.
>> 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.
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 ...
>
> 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?
>
> Of course it is just a proposal, but I thought (and still think) it is 
> really the same problem you were talking about
Indeed.
>
>>>>    * 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?

Bernard


-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, citÚ Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Lešons de Choses <http://mondeca.wordpress.com/>
Received on Wednesday, 27 June 2007 15:57:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:58 GMT