Re: RDFS domain/range issues (was: a view of SPIN constraints)

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 Tuesday, 4 November 2014 10:31:40 UTC