- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 04 Nov 2014 16:52:38 +1000
- CC: public-data-shapes-wg@w3.org
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. 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. 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 06:55:14 UTC