Re: [SKOS] central issues

Hi Bernard,
>
> Hi Antoine
>
> Antoine Isaac a écrit :
>>>    * Should broader/narrower link concepts of the same concept 
>>> scheme, or are they allowed across concept schemes?
>>
>> Does draft proposal I posted for mapping [1] bring an answer to your 
>> question? The idea would be expressing conceptual mapping across 
>> concept schemes trying to re-use the existing SKOS semantic 
>> relationships when possible ...
> Good answers, but not to my question :-) .
> My question is about the use of broader/narrower, not of other 
> relationships across concept schemes

> 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.

and is the following sentence from [1] not ok as well?

> allowing skos:broader statements to hold between concepts from 
> different concept schemes

Of course it is just a proposal, but I thought (and still think) it is 
really the same problem you were talking about

>>>    * 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.

>>> 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)

Cheers,

Antoine
>
> Bernard
>>
>> Cheers,
>>
>> Antoine
>>
>> [1] 
>> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptualMapping/ProposalOne 
>>

Received on Wednesday, 27 June 2007 13:51:32 UTC