W3C home > Mailing lists > Public > public-swd-wg@w3.org > July 2008

Re: [SKOS] ISSUE-83 semantics of scheme containment properties

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Mon, 28 Jul 2008 17:05:22 +0200
Message-ID: <488DE032.9090602@few.vu.nl>
To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
CC: public-swd-wg@w3.org

Hi Alistair,

> Ah. I've actually implemented the other approach, see <http://www.w3.org/2006/07/SWD/SKOS/reference/master.html#schemes>.
>
>   
>> I agree that the first solution you propose makes the trick from a
>> semantic perspective. But I don't like having an extra vocabulary
>> element just for this...
>>     
>
> In principle I agree with you...
>
>   
>> I had actually written [1] to look a bit like the general entailments
>> of
>> the SKOS Reference, thinking that we could  just have:
>>     
>>> ex:cs skos:hasTopConcept ex:c.
>>> entails
>>> ex:c skos:inScheme ex:cs
>>>       
>
> This is fine to say in the notes, but we need some way of expressing the underlying condition in the data model. I.e. we need some prose sentence that can be included in the class & property definition statements.  
>   

You mean, in the OWL ontology for SKOS? Otherwise I don't see how what 
I've proposed and what you (half) proposed differed that much from what 
is in the current Reference document (see below)
>   
>> Otherwise I think you can indeed introduce a non-named property in an
>> OWL axiom, like (hoping I'm not making any mistake...)
>>
>> skos:hasTopconcept rdfs:subPropertyOf [ a owl:ObjectProperty;
>> owl:inverseOf skos:inScheme .] .
>>     
>
> I originally thought of this, but I'm not sure it's ok. Note in particular that the RDF abstract syntax requires all predicates to be named. I.e. you can't have a triple with a blank node in the predicate position. That's why I'm really not sure about using blank predicates in OWL-like axioms.
>   

I'm sorry but again I'm not sure to understand. In the code above all my 
predicates are named.
I guess a proper OWL reasoner reading this should not ouput inferred 
statements corresponding to the "hidden" property (because indeed you 
cannot have a blank node as a predicate in a graph) but would still use 
that in its internal processes to infer the statements with the inScheme 
that wwe're interested in.
But that's at the level of how the OWL reasoner handles this, I guess we 
can rely on that... (but I admit I'm far from an expert on that)

> The only other way I can think of doing it, without a new URI in the SKOS vocabulary, is to start from how you could express the condition as per the rdf/owl full semantics, e.g. 
>   

But wouldn't that also fail your 'we have to put in it in the OWL 
ontology' stance?
Otherwise I'd be perfectly happy with that.

> "for any X, Y, if <X,Y> is in IEXT(I(skos:hasTopConcept)) then <Y,X> is in IEXT(I(skos:inScheme))"
>
> Then try to express this in plain English, e.g.
>
> "if a concept scheme S has top concept C, then C is ..." 
>
> I trailed off there because I can't think of a clear and unambiguous way to say it.
>   

I think the 'formal' condition addresses perfectly the problem. As for 
the 'pplain English', I don't see why "if a concept scheme S has top 
concept C, then C is a member of the scheme S."


> The third alternative of course is simply to state an inference rule, without any underlying semantic conditions. However I'm reluctant to do that, because it would be the first and only time we include an inference rule in the SKOS data model...

How about these? There are not pure OWL and yet they are in the semantic 
conditions...
"S13      A resource has no more than one value of skos:prefLabel per 
language."
"S34      For any resource, every item in the list given as the value of 
the skos:memberList property is also a value of the skos:member property."

Cheers,

Antoine

>  (has a quick hunt for recent progress on RIF, SWRL, DL-safe rules) ...I guess there are now options for stating inference rules (see e.g. [1]) however knowing very little I fear to open a can of worms.
>
> Hence a new URI and some obvious RDFS and OWL 1 axioms seems like the safest option.
>
> What do you think?
>
> Cheers,
>
> Al.
>
> [1] http://code.google.com/p/owl1-1/wiki/SafeRulesOverview
>
>   
>> Again, I would definitively favor one of these two options over
>> introducing a new property.
>>
>> Cheers,
>>
>> Antoine
>>
>> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008May/0068.html
>>
>>
>>     
>>> Hi Antoine,
>>>
>>> I'm just trying to figure out how to implement the resolution [1] to
>>> issue 83 [2] in the SKOS reference.
>>>
>>> The most obvious way is to introduce a new property, called something
>>> like skos:topConceptInScheme, and introduce two new statements into
>>>       
>> the
>>     
>>> SKOS data model, that skos:topConceptInScheme is a sub-property of
>>> skos:inScheme, and that skos:topConceptInScheme is the inverse of
>>> skos:hasTopConcept.
>>>
>>> Another way would be to avoid introducing any new properties, and to
>>> include a new statement in the data model, something like, "the
>>>       
>> inverse
>>     
>>> of skos:hasTopConcept is a sub-property of skos:inScheme", or "if a
>>> scheme has a top concept, then the top concept is in that scheme",
>>> or ... ?
>>>
>>> At the moment I favour the first approach. It has an obvious meaning
>>>       
>> in
>>     
>>> terms of RDFS/OWL. The second approach has no obvious translation in
>>> RDFS/OWL, and is difficult to word.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>>
>>> Al.
>>>
>>> [1] http://lists.w3.org/Archives/Public/public-swd-
>>>       
>> wg/2008May/0068.html
>>     
>>> [2] http://www.w3.org/2006/07/SWD/track/issues/83
>>>
>>>
>>>       
>
>
>
> --
> Alistair Miles
> Senior Computing Officer
> Image Bioinformatics Research Group
> Department of Zoology
> The Tinbergen Building
> University of Oxford
> South Parks Road
> Oxford
> OX1 3PS
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: alistair.miles@zoo.ox.ac.uk
> Tel: +44 (0)1865 281993
>
>
>
>   
Received on Monday, 28 July 2008 15:05:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:52 UTC