Re: [SKOS] Amsterdam topic " Drawing the Pictures" (was RE: some thoughts about ISSUE 35 ConceptSchemeContainment)

Hi Doug,

Indeed your mail arrived a couple of hours before we started discussing 
these issues in our plenary :-)

The solution that was agreed on is to keep skos:hasTopConcept, and to 
replace skos:inScheme by rdfs:isDefinedBy
(inScheme staying, but just as a subproperty of isDefinedBy to deal with 
legacy SKOS data)
as well as allowing people who want to use name graphs or ontologies as 
concept schemes to do so.
So, there is still a way to link exlicitly concept to their schemes. 
Does it fit your need?

Thanks once again for your very useful input,

Antoine

> We see some of the arguments but are concerned about the implications of
> having only a very abstract connection between a SKOS concept and
> concept scheme and relegating it to the primer. 
>
> We're currently developing applications involving the need to connect
> SKOS concepts with particular schemes. (It's not just a matter of rights
> and trust). We also make use of TopConcept and think relying on query
> may be problematic for interactive applications.
>
> Hopefully the practical implications and use cases can be considered
> before coming to a final decision.
>
> Regards
>
> Doug
>
> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org] On Behalf Of Guus Schreiber
> Sent: 07 October 2007 21:59
> To: Miles, AJ (Alistair)
> Cc: SWD WG; public-esw-thes@w3.org
> Subject: Re: [SKOS] Amsterdam topic " Drawing the Pictures" (was RE:
> some thoughts about ISSUE 35 ConceptSchemeContainment)
>
>
>
>
> Miles, AJ (Alistair) wrote:
>   
>> Hi all,
>>
>> As input to discussion of "Drawing the Pictures", I've written a
>>     
> strawman for the semantics of skos:ConceptScheme...
>   
>> [1]
>>     
> <http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemes/MinimalPro
> posal?action=recall&rev=1>
>   
>> This semantics is very minimal, and quite permissive. 
>>
>> At the moment, I favour this approach, because I don't think we have
>>     
> enough experience yet to rule anything out. We are also not trying to go
> beyond or reinvent what can already be done with existing technologies
> (SPARQL and OWL).
>   
>> Note that this proposal implicitly deprecates skos:inScheme, and
>>     
> delegates the job of describing best practices for using
> rdfs:isDefinedBy instead to the SKOS Primer.
>   
>> I think this proposal is compatible with Guus' below, but also should
>>     
> address most of the concerns raised in subsequent emails on that thread.
>
> I'm in favor of this proposal. The nice thing is 
> that it follows the principle of minimal 
> commitment. An follow-up action should be to write 
> some practical uses/implications.
>
> Guus
>
>   
>> Cheers,
>>
>> Alistair.
>>
>>
>>     
>>> -----Original Message-----
>>> From: public-swd-wg-request@w3.org 
>>> [mailto:public-swd-wg-request@w3.org] On Behalf Of Guus Schreiber
>>> Sent: 25 July 2007 20:59
>>> To: SWD WG
>>> Subject: some thoughts about ISSUE 35 ConceptSchemeContainment
>>>
>>>
>>> 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 Wednesday, 10 October 2007 08:37:00 UTC