Re: RDFS domain/range issues

On 06 Nov 2014, at 09:55, Holger Knublauch <holger@topquadrant.com> wrote:

> Hi Axel,
> 
> which problems would your suggestion solve that are not already solved by SPIN?

none, but it is meant as a minimal common core that unifies SPIN and ICV, for instance. 

> I think we have enough solution candidates on the table and I would be against inventing yet something new unless there are clear advantages.

I didn't propose to reinvent anything, my feeling is that this proposal is perfectly compatible with SPIN, or no?
If not, where is it not?

> For example, SPIN already has tool support, and has already been evaluated by practitioners for five years. I'd rather use SPIN as a starting point and add missing features.
> 
> Also why should range/domain have any special treatment compared to, for example, cardinality?

Cardinality constraints on resources would expressible in shapes:constrainedBy on any resource of a certain type.

Again, I was not trying to reinvent anything, my sole purpose was to identify the minimum *common core*  
between seemingly orthogonal proposals such as SPIN and ICV on the table, which to my understanding 
boils down to these three properties. If my understanding is wrong, please clarify where I am missing the point in your opinion, thanks!

best regards,
Axel

> Holger
> 
> 
> On 11/6/14, 6:38 PM, Axel Polleres wrote:
>> Hi Holger/Peter,
>> 
>> rethinking what I wrote below, it seems to me that a unifying proposal for the SHAPES WG on how to constrain resources and properties
>> *could* be quite straightforward, in a way that is compatible at least with SPIN and ICV, please let me know if you think that this understanding is correct...
>> 
>> The qroup could define as a minimal core *3* RDF propoerties
>> 
>>    shapes:constrainedBy
>>    shapes:domainConstrainedBy
>>    shapes:rangeConstrainedBy
>> 
>> as follows:
>> 
>> 1)
>> shapes:constrainedBy
>>    domain: either a Class Definition or a unary SPARQL Query.
>>    range:  either a Class Definition or a unary SPARQL Query.
>> 
>> Semantics: any resource wich is entailed to satisfy the lhs has to be entailed the rhs (obviously, this can be combined with any entailment regimes R , i.e. "entailed" here meaning to be a certain answer it can be the certain under entailment regime R.)
>> 
>> 2)
>> shapes:domainConstrainedBy
>>    domain: either a property name or a unary SPARQL Query.
>>    range:  either a Class Definition or a unary SPARQL Query.
>> 
>> Semantics: for any resource P that is entailed to satisfy the lhs, any subject S of any triple S P O known to be entailed by the dataset, has to be has to be entailed the rhs.
>> 
>> 
>> 3)
>> shapes:rangeConstrainedBy
>>    domain: either a property name or a unary SPARQL Query.
>>    range:  either a Class Definition or a unary SPARQL Query.
>> 
>> Semantics: for any resource P that is entailed to satisfy the lhs, any object O of any triple S P O known to be entailed by the dataset, has to be has to be entailed the rhs.
>> 
>>  
>> Does that make sense? I believe ICV - as I understand it - would be compatible with 1) (not sure whether 2) and 3) are treated as well there, to be honest)... also, in spirit this should be compatible with what SPIN allows, right? If those assumptions are correct, could this be a unifying basis (on top of which we may define further shortcuts/macros/rules)?
>> 
>> 
>> best,
>> Axel
>> 
>> 
>>  --
>> Prof. Dr. Axel Polleres
>> Institute for Information Business, WU Vienna
>> url: http://www.polleres.net/  twitter: @AxelPolleres
>> 
>> On 05 Nov 2014, at 10:37, Axel Polleres <axel.polleres@wu.ac.at> wrote:
>> 
>>> On 05 Nov 2014, at 09:59, Holger Knublauch <holger@topquadrant.com> wrote:
>>>> Did you mean to replace rdfs:subClassOf with owl:constraint?
>>> No. I only meant to have shapes:constraint as an alternative for owl:restriction.
>>> 
>>> A "constraint-reading" of subclassOf (or subpropertyOf), however you would syntactically denote it,
>>> would be IMO something orthogonal/different to that,
>>> frankly, it is not even clear to me what it should mean.
>>> a) that all *explicit* instances of the subclass have to be  *explicitly* typed to the superclass within the dataset?
>>> b) that all *implicit* instances of one subclass have to be  *explicitly* typed to the superclass within the dataset?
>>> c) something else?
>>> 
>>> Opinions welcome...
>>> 
>>>> That may be even less of an issue.
>>>> 
>>>> How did the community react on your suggestions in the paper? Where did it lead to?
>>> not sure... seems eventually it lead to this group, maybe?... 10 years later ;-)
>>> 
>>> More seriously, there was a huge body of work on how to combine OWA and CWA, or,
>>> likewise UNA and non-UNA/equality reasoning formalisms coming after or around the same time
>>> (I could now attach a list of 10s of papers, if you wish explicitly, not sure whether that falls
>>> in the scope of our work here entirely)... In my personal opinion, I wouldn't consider this
>>> work having a single one-size-fits-all solution had emerged on how to combine monotonic/open-world
>>> formalisms with non-monotonic/closed-world ones, so I guess we should try to stay on "safe" terrain.
>>> 
>>> There's a variety of coin-flip decisions that need to be taken when combining constraint-checking or
>>> query answering with ontologies. E.g., SPARQL1.1 entailment regimes is one example of a standard which
>>> has done so, where arguable it is not the single and only solution. (Take for instance using an ASK
>>> query with COUNT() for checking cardinalities which differs from checking a cardinality restriction
>>> in OWL, etc...)
>>> 
>>> best,
>>> Axel
>>> 
>>>> Holger
>>>> 
>>>> 
>>>> On 11/5/14, 6:48 PM, Axel Polleres wrote:
>>>>> FWIW, "back in the old days" we had made a similar suggestion, replacing owl:restriction with something like "owl:constraint", cf. [1].
>>>>> Notes that rdfs:domain/rdfs:range can be likewise "read" as an owl:allValluesFrom restriction.
>>>>> That is:
>>>>> 
>>>>> P rdfs:range C
>>>>> =
>>>>> restriction (P allValuesFrom C)
>>>>> 
>>>>> P rdfs:domain C
>>>>> =
>>>>> restriction (P- allValuesFrom C)
>>>>> 
>>>>> so, alternativelty allowing a keyword owl:constraint instead of owl:restriction could solve some (most?) of the cases of reading owl restrictions as constraints, right?
>>>>> 
>>>>> Axel
>>>>> 
>>>>> 
>>>>> 1. Jos De Bruijn, Axel Polleres, Rubén Lara, and Dieter Fensel. OWL DL vs. OWL Flight: Conceptual modeling and reasoning for the semantic web. In Proceedings of the 14th World Wide Web Conference (WWW2005), pages 623-632, Chiba, Japan, May 2005. ACM Press.
>>>>> http://www.polleres.net/publications/debr-etal-2005.pdf
>>>>> 
>>>>> 
>>>>> --
>>>>> Prof. Dr. Axel Polleres
>>>>> Institute for Information Business, WU Vienna
>>>>> url: http://www.polleres.net/  twitter: @AxelPolleres
>>>>> 
>>>>> On 05 Nov 2014, at 01:21, Holger Knublauch <holger@topquadrant.com> wrote:
>>>>> 
>>>>>> 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 Thursday, 6 November 2014 09:47:26 UTC