Re: some thoughts about ISSUE 35 ConceptSchemeContainment

First, I am not too familiar with with the implications of owl:Ontology 
and  owl:import.
 
I am really using the inScheme property in my applications to define 
different "views"
(coexisting in one repository)
- define different sub-set ofs Concepts: CS hasTopConcept Ci  but also 
Cj skos:inScheme CS
- define different coexisting sets of skos:broader/narrower relations
  (by means of not so nice - ad hoc - requiring subject and object to be 
in the ConceptScheme).

As a concrete example we use mappings between two SKOS thesauri to make 
2 collections annotated by
the two thesauri accessible by either one of them(no problem there, 
those Concepts are disjunct).
It also proved useful to define a "merged thesaurus", where e.g. a 
C1thes1 skos:broadMatch C2thes2
would lead to a merged thesaurus having C1thes1 skos:broader C2thes2.

What we do now: leave both thesauri in the repository with their 
ConceptScheme defining their elements,
but requiring skos:broader/narrower subjects and objects to have 
matching Conceptschemes, and adding a
new ConceptScheme, defining extra broader/narrower links, and extra 
hasTopConcept
properties and by adding skos:inScheme properties.
(See this at work in our old demo Iconclass+ARIA: 
http://stitch.cs.vu.nl/rp33333/MERGEDVIEW-E-ALL)

Of course the ideal solution would be to have the broader/narrower links 
(but preferably concepts too!) explicitly tagged
by a ConceptScheme, and have sufficiently powerful reasoning facilities 
for using such tags(preferably with tag/ConceptScheme
aspects handled the same way as other aspects).
 Using inScheme, with the current state of technology solves my problem. 
I do not really understand the details of the
proposed solution but does it imply allowing distinction within one 
repository of having multiple distinguishable
 broader relationship graphs between shared Concepts? (I hope it does, 
and I hope it is implemented in enough "standard rdf
 reasoners").

(Another use case is a Taxonomical thesaurus where an expert and a 
layman should be presented with a different
hierarchy of shared Concepts)

Lourens



Guus Schreiber wrote:
>
>
>
> Bernard Vatant wrote:
>>
>> I second Antoine on this.
>>
>> Although I have been wondering about the subtle differences between 
>> using ConceptScheme vs subClassOf Concept, there is at least one 
>> feature of ConceptScheme which I would not give up, it's 
>> hasTopConcept. Actually, the inScheme declarations are 
>> useless/redundant if you consider the narrower property to be 
>> internal to a ConceptScheme, in which case the containment in a 
>> ConceptScheme can be entailed from the hasTopConcept declaration(s). 
>> A ConceptScheme "contains" all its declared top concepts and their 
>> descendants in the broader-narrower hierarchy.
>
> Bernard, Antoine,
>
> My main point was about the problems with skos:inScheme,  I can live 
> with skos:ConceptScheme an skos:hasTopConcept.
> Guus
>
>>
>> Bernard
>>
>>
>> Antoine Isaac a écrit :
>>>
>>> Hello,
>>>
>>> I'm sorry for being picky once again, but I disapprove of almost all 
>>> this, mainly for useability reasons:
>>>
>>> 1. using owl:ontology as a substitute for skos:ConceptScheme is 
>>> dangerous, because people will confuse concepts with class even more 
>>> than what is now. We'll need to document this extensively, possibly 
>>> using the idea of ConceptScheme again, so I'm worried.
>>>
>>> 2. owl:imports defines importing on an ontology basis: if you want 
>>> to import just some concepts and/or if you want to change the links 
>>> between them to have your own view on the domain, you're going into 
>>> a mess
>>>
>>> 3. as I already mentioned discussing with Alistair on using complex 
>>> algorithms to handle his solution for concept grouping, I disapprove 
>>> of all that could make one user's life a hell. And I think relying 
>>> on querying (vs. explicit representation) for accessing all kind of 
>>> needed information harms the use of the model. Take the example of 
>>> the RDFS query engines that have implemented a predicate like 
>>> "directSubClassOf" to access direct link between classes (which you 
>>> can do by making your query just a little bit more comple) : there 
>>> must be a reason...
>>>
>>> 4. finally I'm sceptical about the use of namespaces or RDF-based 
>>> solutions for provenance/trust (like quadruples or named graphs) to 
>>> handle concept scheme information. To me these are based on 
>>> knowledge source (that we trust or not, etc.) and I think there is 
>>> no bijection between a knowledge source and a concept scheme: a same 
>>> source could provide information about several concept schemes and 
>>> different (trusted) sources could contribute to define a same 
>>> scheme. I don't say that's impossible, I just want to warn that this 
>>> call for thinking about different cases and solutions, as well as 
>>> writing pages of guidelines that we might not have the time for.
>>>
>>> Also, I think this mail shall definitevely forwarded to the SKOS 
>>> mailing list, which could give us very interesting comments on this 
>>> idea of dropping concept scheme information
>>>
>>> Antoine
>>>
>>> Daniel Rubin a écrit :
>>>>
>>>> I second this
>>>>
>>>> At 12:59 PM 7/25/2007, Guus Schreiber wrote:
>>>>
>>>>> Issue description: http://www.w3.org/2006/07/SWD/track/issues/36
>>>>>
>>>>> Synopsis of the issue: SKOS provides a mechanism to indicate that 
>>>>> a concept is contained in a concept scheme (the property 
>>>>> skos:inScheme), but it is nontrivial to define such containment 
>>>>> for relation between concepts (e.g. broader/narrower).
>>>>>
>>>>> The whole notion of containment in a thorny one in a Semantic Web 
>>>>> setting. Note that OWL ontologies do not have a language construct 
>>>>> for this. It is understandable that some way of saying that "these 
>>>>> elements are part of my vocabulary" is useful for vocabulary 
>>>>> owners. However, it is doubtful whether we can try to solve this 
>>>>> at the level of SKOS. The reasons for wanting to define 
>>>>> containment typically have to do with issues such as trust and 
>>>>> rights. In my view such mechanisms should be provided at the 
>>>>> general RDF level. We shouldn't try to solve this issue with a 
>>>>> special-purpose construct in SKOS.
>>>>>
>>>>> I therefore propose to deprecate the property skos:inScheme.
>>>>>
>>>>> I suggest to include in our documents guidelines for how to handle 
>>>>> containment issues, e.g. by making using of rdf:isDefinedBy or by 
>>>>> relying on through guidelines for querying.
>>>>>
>>>>> I could also go one step further and propose to drop also the 
>>>>> class skos:ConceptScheme and the property skos:hasTopConcept. 
>>>>> Instead of skos:ConceptScheme SKOS users could just use the OWL 
>>>>> construct owl:Ontology, which also provides an import construct 
>>>>> (owl:import). Finding the top concepts could just be handled at 
>>>>> the query level. However, skos:ConceptScheme (and 
>>>>> skos:hasTopCncept) could be just viewed as a useful documentation 
>>>>> vehicle.
>>>>>
>>>>> Guus
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>

Received on Thursday, 26 July 2007 14:31:40 UTC