Re: RDFS domain/range issues

Axel,

I think the original topic that started the discussion was about whether 
the SPIN engine observes RDFS semantics or not, and my answer to this is 
that it only honors rdfs:subClassOf and subPropertyOf (of 
spin:constraint) but leaves any kind of inferencing (such as 
rdfs:domain/range) up the triple store level.

*This means that SPIN can be combined with OWL/RDFS but does not depend 
on it*

The question that you raise is certainly important too: whether it is a 
good practice to reuse and overload existing OWL/RDFS vocabulary that 
was invented for different use cases and with different semantics for 
ontology building. I guess this question is hard to answer. On one hand 
side, it sounds like an ugly hack to change the semantics of some term 
only because another triple is present in a graph. On the other hand, 
OWL and RDFS have been there first, and there is now a large corpus of 
existing ontologies. We need to suggest a way forward for those existing 
ontologies.

There are many ways to overcome this problem, and I believe that the 
mechanism of attaching SPIN constructs to OWL/RDFS class definitions 
already brings most benefits with it. The owl:Restrictions that are 
present in the real world are usually easy to either re-interpret at 
run-time, convert into or duplicate as shape expressions. But that's a 
longer topic that we need to discuss thoroughly in the WG.

Overall I do agree with your concerns about overloading terms, and I 
have heard these same concerns from others.

Holger


On 11/4/2014 20:31, Axel Polleres wrote:
> On 04 Nov 2014, at 07:52, Holger Knublauch <holger@topquadrant.com> wrote:
>
>> Hi Axel,
>>
>> I believe the main problem with rdfs:domain (and range) is that it it doesn't align with the expectation that people familiar with object-oriented systems have. If "they" see ex:parent rdfs:range ex:Person then they assume that all parents must be Persons. However, the presence of such a triple doesn't restrict the value space, but rather leads to the *inference* that any parent must (also) be a Person. Similar for rdfs:domain. Likewise, the expectation of multiple domain statements is that of a union and not an intersection.
>>
> Well, I don't think we should redefine/overload the semantics here. So, if we were to define some constraining versions of these terms, we should IMHO use different vocabulary. On the other hand, I admit this is kind of a similar way as "abusing the owl-vocabulary in ICV, yes?
>
>> Our practical experience suggests that rdfs:range and rdfs:domain get misunderstood all the time, and I wouldn't base a new language on them unless there are strong other reasons to do so. See schema.org - they ended up defining their own replacements for range and domain.
> ... so we agree, that we don't want to overload the terms?
>
> best reagrds,
> Axel
>
>
>> I do not complain about rdfs:subClassOf (and to a lesser degree rdfs:subPropertyOf) - these are generally easy to understand.
>>
>> HTH
>> Holger
>>
>>
>> On 11/4/2014 16:41, Axel Polleres wrote:
>>> Hi,
>>>
>>> @Peter: are you referring to what is commonly referred to as "non-standard use" of the RDFS vocabulary?
>>> Cf. http://books.google.at/books?id=Ah_pAwAAQBAJ&pg=PA105 Def.5.5
>>>
>>>
>>> @Holger: While I agree that non-standard use can lead to unintuitive behavior, I don't agree
>>> with the general statement, that
>>>
>>>>>   RDFS doesn't have intuitive semantics, esp rdfs:domain and range are a source of
>>>>> frequent user pain.
>>> I think that the semantics of subclassOf,subPropertyOf, domain, and range is very
>>> straightforward...
>>> Can you explain in more detail what you mean by "frequent user pain" here, or was it
>>> only non-standard use you were referring to here?
>>>
>>> best,
>>> Axel
>>>
>>> --
>>> Prof. Dr. Axel Polleres
>>> Institute for Information Business, WU Vienna
>>> url: http://www.polleres.net/  twitter: @AxelPolleres
>>>
>>> On 04 Nov 2014, at 04:37, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>>
>>>> Well not only subproperties of rdf:type but also subproperties of rdfs:subClassOf.
>>>>
>>>> peter
>>>>
>>>>
>>>> On 11/03/2014 12:58 PM, Holger Knublauch wrote:
>>>>> On 11/4/14, 3:06 AM, Peter F. Patel-Schneider wrote:
>>>>>> One aspect of this definition is that SPIN does not completely abide by the
>>>>>> RDFS definition of the instances of classes.
>>>>> Could you clarify - do you mean sub-properties of rdf:type?
>>>>>
>>>>> And in general, it is not the goal of SPIN to have full RDFS support. RDFS
>>>>> doesn't have intuitive semantics, esp rdfs:domain and range are a source of
>>>>> frequent user pain.
>>>>>
>>>>> Thanks
>>>>> Holger
>>>>>
>>>>>
>>>>>> peter
>>>>>>
>>>>>> On 10/31/2014 01:04 PM, Holger Knublauch wrote:
>>>>>>> Yeah that looks right. I think we only need to define the semantics of the
>>>>>>> CONSTRUCT case and treat ASK as syntactic sugar with default values for the
>>>>>>> constructed ConstraintViolations.
>>>>>>>
>>>>>>> Holger
>>>>>>>
>>>>>>>
>>>>>>> On 11/1/14, 4:05 AM, Peter F. Patel-Schneider wrote:
>>>>>>>> Here is my reconstruction of how SPIN constraints work, based on my reading
>>>>>>>> of various SPIN documents and various presentations about SPIN constraints.
>>>>>>>> Please let me know if anything is wrong.
>>>>>>>>
>>>>>>>> Conceptually a SPIN constraint system takes in two inputs:
>>>>>>>> 1/ an RDF graph
>>>>>>>> 2/ a set of SPIN constraints
>>>>>>>>
>>>>>>>> Each SPIN constraint is attached to a class and provides a constraint in the
>>>>>>>> form of a SPARQL query fragment plus an optional SPARQL construct clause.
>>>>>>>> The surface syntax may not always look like query fragments and construct
>>>>>>>> clauses, but the only things that determine the meaning of a SPIN
>>>>>>>> constraint are the query fragment and construct clause that can be generated
>>>>>>>> from the surface syntax.
>>>>>>>>
>>>>>>>> A constraint with SPARQL query fragment F on class C is satisfied if the
>>>>>>>> SPARQL query
>>>>>>>>    ASK {
>>>>>>>>      ?this rdf:type/rdfs:subClassOf* C .
>>>>>>>>      F }
>>>>>>>> returns no bindings for the graph G
>>>>>>>>
>>>>>>>> If there is a construct clause X then the result of the constraint is the
>>>>>>>> result of the SPARQL query
>>>>>>>>    CONSTRUCT { X }
>>>>>>>>    WHERE {
>>>>>>>>     ?this rdf:type/rdfs:subClassOf* C .
>>>>>>>>     F }
>>>>>>>> evaluated against the graph G.
>>>>>>>>
>>>>>>>>
>>>>>>>> peter
>>>>>>>>
>>

Received on Wednesday, 5 November 2014 00:23:40 UTC