- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 03 Nov 2014 23:10:50 -0800
- To: Axel Polleres <axel.polleres@wu.ac.at>
- CC: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
Well, one might call this non-standard, but there were quite a few defenders of it, at least at one time. Certainly this does not fit into the description logic view of RDF or RDFS. I am not referring to really weird things like making rdfs:subClassOf a sub-property of rdfs:subPropertyOf. peter On 11/03/2014 10:41 PM, 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 07:11:24 UTC