- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 11 Nov 2014 02:16:48 -0500
- To: Peter Patel-Schneider <pfpschneider@gmail.com>
- Cc: public-data-shapes-wg@w3.org, Arthur Ryman <ryman@ca.ibm.com>
- Message-ID: <CANfjZH1_ZpjOpRdaxNFC-DtJfa2-9wCeeP9-z0LQZ8tOyjgSQw@mail.gmail.com>
On Nov 10, 2014 6:55 PM, "Eric Prud'hommeaux" <eric@w3.org> wrote: > > * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-10 09:52-0800] > > So in basic SPARQL the basic graph pattern > > ex:a ex:b "1"^^xsd:integer . > > does not match the RDF graph > > ex:a ex:b "01"^^xsd:integer . > > > > In an entailment regime that includes integer as a datatype, the > > above pattern does match the graph. > > In principle, if you ever found that entailment regime supported. > Usually folks just give up and write: > ex:a ex:b ?o FILTER (?o = 1) # bareword is an integer > or if they're after the leading 0s: > ex:a ex:b ?o FILTER (?o = "01"^^xsd:integer) Sorry, 2nd example should have been FILTER (same term(?o, "01"^^xsd:integer )) If one is specifically looking for "01". > > peter > > > > > > On 11/10/2014 09:45 AM, Eric Prud'hommeaux wrote: > > >* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-10 08:13-0800] > > >>Well, there are multiple semantics for SPARQL 1.1 if you look at the > > >>entailment regimes. We could say, for example, that the semantics > > >>of shapes/constraints are to be specified in terms of the RDFS > > >>entailment regime for SPARQL. This would provide a tie to SPARQL as > > >>well as providing the right meaning for rdf:type, rdfs:subClassOf, > > >>rdfs:domain, and rdfs:range. > > >> > > >>It does appear that SPARQL without entailment regimes is sensitive > > >>to the surface form of literals. Can anyone determine whether this > > >>is true? > > > > > >SPARQL graph matching tests for RDF term equivalence per the abstract > > >syntax. If it looks different, it, aside from "ab"@en and "ab"@EN. > > >There are a bunch of operators that add more kinds of equivalence in > > >expressions (FILTER and BIND). > > > http://www.w3.org/TR/sparql11-query/#OperatorMapping > > >The following FILTER is true: > > > FILTER ("1"^^xsd:integer = "01"^^xsd:integer) > > >You can test for pedantic (or cheap) RDF equivalence with sameTerm(A,B): > > >http://www.w3.org/TR/sparql11-query/#func-sameTerm > > > > > > > > >>peter > > >> > > >>PS: SPARQL 1.1 (the current version) is defined in terms of the > > >>2004 version of RDF, not RDF 1.1. > > >> > > >> > > >>On 11/10/2014 07:38 AM, Arthur Ryman wrote: > > >>>Peter, > > >>> > > >>>I am proposing that we define the semantics of shapes/constraints in terms > > >>>of the data model specified in the RDF 1.1 spec. which does not include > > >>>classes, RDFS, etc. This is how the semantics of SPARQL is defined. > > >>> > > >>>Classes, RDF, OWL, rules, etc. enter in as ways to infer new graphs from > > >>>given graphs (entailment). Shapes/constraints may apply to either the raw > > >>>graph or the inferred graph, depending in the application. > > >>>_________________________________________________________ > > >>>Arthur Ryman > > >>>Chief Data Officer > > >>>SWG | Rational > > >>>905.413.3077 (phone) | 416.939.5063 (cell) > > >>>IBM InterConnect 2015 > > >>> > > >>> > > >>> > > >>> > > >>>From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com> > > >>>To: "Eric Prud'hommeaux" <eric@w3.org>, > > >>>Cc: Arthur Ryman/Toronto/IBM@IBMCA, public-data-shapes-wg@w3.org > > >>>Date: 11/07/2014 09:23 AM > > >>>Subject: Re: Shapes, Individuals, and Classes - OSLC Motivations > > >>> > > >>> > > >>> > > >>>OK, so then it's not just RDF graphs, it's something else. What is this > > >>>else? > > >>> > > >>>peter > > >>> > > >>> > > >>>On 11/07/2014 05:45 AM, Eric Prud'hommeaux wrote: > > >>>>* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-06 > > >>>20:36-0800] > > >>>>>So your view is that all that counts is the graph? Nothing about > > >>>>>datatypes, or RDF, or RDFS? > > >>>> > > >>>>I suspect that OSLC wants datatypes, noting that Resource Shapes has > > >>>>an oslc:valueType predicate for identifying the datatype of a literal. > > >>>> > > >>>> http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#valueType > > >>>> > > >>>> > > >>>>>peter > > >>>>> > > >>>>> > > >>>>>On 11/06/2014 12:01 PM, Arthur Ryman wrote: > > >>>>>>Peter, > > >>>>>> > > >>>>>>Commenting on your proposed wording of how to express the "decoupling" > > >>>>>>requirement. I'd go further and demote the notion of class to being > > >>>more > > >>>>>>like just another property and view the shape/constraints as applying > > >>>to > > >>>>>>the RDF representation of an information resource, i.e. to a set of > > >>>>>>triples (aka an RDF graph). Some of the triples will have rdf:type as > > >>>the > > >>>>>>predicate and those triples are useful for locating certain subject > > >>>nodes > > >>>>>>that we want to say more things about, e.g that they are the subjects > > >>>of > > >>>>>>triples that have certain other predicates, etc. > > >>>>>>_________________________________________________________ > > >>>>>>Arthur Ryman > > >>>>>>Chief Data Officer > > >>>>>>SWG | Rational > > >>>>>>905.413.3077 (phone) | 416.939.5063 (cell) > > >>>>>>IBM InterConnect 2015 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com> > > >>>>>>To: Arthur Ryman/Toronto/IBM@IBMCA, > > >>>>>>Cc: public-data-shapes-wg@w3.org > > >>>>>>Date: 11/06/2014 12:14 PM > > >>>>>>Subject: Re: Shapes, Individuals, and Classes - OSLC > > >>>Motivations > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>I still don't know what "custom" means here with respect to RDF. As > > >>>far > > >>>>>>as I > > >>>>>>can tell any bit of an ontology, or class, or property, or constraint, > > >>>or > > >>>>>>shape could be called "custom". Now it may be that within OSLC there > > >>>is > > >>>>>>some > > >>>>>>notion of custom vs non-custom, but how can that notion be removed > > >>>from > > >>>>>>OSLC > > >>>>>>so that it can be used elsewhere? > > >>>>>> > > >>>>>>Similarly, the notions of "specification", "implementation", > > >>>"project", > > >>>>>>etc., > > >>>>>>appear to me to be specific to OSLC, and particular to the design > > >>>>>>methodology > > >>>>>>you outline below, and using them to drive a spec could, I think, tie > > >>>that > > >>>>>> > > >>>>>>spec quite closely to the design methodology. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>As a contrast, here is what I believe should be used to say that > > >>>classes > > >>>>>>and > > >>>>>>shapes/constraints are decoupled. > > >>>>>> > > >>>>>>Definition: Classes and shapes/constraints are decoupled if the > > >>>>>>specification > > >>>>>>can use different sets of shapes/constraints on the same class. For > > >>>>>>example, > > >>>>>>if the specification permits the ontology > > >>>>>> ex:Person rdf:type rdfs:Class . > > >>>>>> ex:name rdf:type rdf:Property . > > >>>>>> ex:name rdfs:domain ex:Person . > > >>>>>>to be used with the constraint set > > >>>>>> ex:Person < exists ex:name > > >>>>>>(every person has a "known" value for its name) > > >>>>>>or used with the constraint set > > >>>>>> ex:Person < all ex:name xsd:string > > >>>>>>(all "known" names of people are strings) > > >>>>>>then it will be said to allow the decoupling of constraints/shapes and > > >>>>>>classes. > > >>>>>> > > >>>>>> > > >>>>>>A stronger notion would be that shapes/constraints are independent of > > >>>>>>classes. > > >>>>>> This could be defined as: > > >>>>>> > > >>>>>>Definition: Classes and shapes/constraints are independent if some > > >>>>>>shapes/constraints do not use class membership in their definition. > > >>>For > > >>>>>>example, the following constraint is class-independent: > > >>>>>> exists ex:name < exactly 1 ex:name > > >>>>>>(if something has a "known" name then it has exactly one "known" name) > > >>>>>> > > >>>>>> > > >>>>>>peter > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>On 11/06/2014 04:59 AM, Arthur Ryman wrote: > > >>>>>>>Peter, > > >>>>>>> > > >>>>>>>OSLC defines specification for RDF representation of resources in > > >>>>>>several > > >>>>>>>domains, e.g. Requirements, Quality, Change Management etc. A > > >>>>>>>specification typically defines a class and several properties. > > >>>>>>>Implementations are allowed to add new RDF properties but they don't > > >>>>>>>necessarily introduce new RDF classes. Furthermore, within an > > >>>>>>>implementation, users may add custom RDF properties on a > > >>>>>>>project-by-project basis, but that doesn't change the RDF class. > > >>>>>>Therefore > > >>>>>>>different projects use different Shapes but the Shapes only differ by > > >>>>>>RDF > > >>>>>>>properties, not RDF classes. That is what I mean by decoupling Shapes > > >>>>>>and > > >>>>>>>Classes. > > >>>>>>> > > >>>>>>>I will elaborate this on the wiki. > > >>>>>>>_________________________________________________________ > > >>>>>>>Arthur Ryman > > >>>>>>>Chief Data Officer > > >>>>>>>SWG | Rational > > >>>>>>>905.413.3077 (phone) | 416.939.5063 (cell) > > >>>>>>>IBM InterConnect 2015 > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com> > > >>>>>>>To: Arthur Ryman/Toronto/IBM@IBMCA, public-data-shapes-wg@w3.org, > > >>>>>>>Date: 11/05/2014 05:27 PM > > >>>>>>>Subject: Re: Shapes, Individuals, and Classes - OSLC > > >>>Motivations > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>I'm still wondering what you think it means to decouple shapes and > > >>>>>>>classes. > > >>>>>>>The first motivation you provide is supported by both SPIN and OWL > > >>>>>>>constraints. I can't figure out what custom properties have to do > > >>>with > > >>>>>>>classes, or constraints, or shapes. The behaviour you appear to be > > >>>>>>>looking > > >>>>>>>for in your second paragraph is also supported by both SPIN and OWL > > >>>>>>>constraints. > > >>>>>>> > > >>>>>>>I had thought that this was ironed out at the Face-to-Face, but I > > >>>guess > > >>>>>>>not. > > >>>>>>> > > >>>>>>>peter > > >>>>>>> > > >>>>>>> > > >>>>>>>On 11/05/2014 01:47 PM, Arthur Ryman wrote: > > >>>>>>>>There are a few motivations for decoupling shapes and classes. One > > >>>is > > >>>>>>>that > > >>>>>>>>the creation shape may be different than the update shape. Another > > >>>has > > >>>>>>>to > > >>>>>>>>do with custom properties. I'll write up the following in the wiki. > > >>>>>>>> > > >>>>>>>>OSLC supports an open content model for resources. It is common for > > >>>>>>>tools > > >>>>>>>>to add their own custom properties, and for projects within a tool > > >>>to > > >>>>>>>have > > >>>>>>>>different user-defined properties. For example, consider a bug > > >>>tracking > > >>>>>>>>tool. Project A may add a custom property foo and project B may add > > >>>>>>bar. > > >>>>>>>>All projects use the same RDF type for bug resources, e.g. > > >>>>>>>>oslc_cm:ChangeRequest. However, the shape for resources in project A > > >>>>>>>>differs for the shape for project B. > > >>>>>>>>_________________________________________________________ > > >>>>>>>>Arthur Ryman > > >>>>>>>>Chief Data Officer > > >>>>>>>>SWG | Rational > > >>>>>>>>905.413.3077 (phone) | 416.939.5063 (cell) > > >>>>>>>>IBM InterConnect 2015 > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >>> > > >>> > > > > > -- > -ericP > > office: +1.617.599.3509 > mobile: +33.6.80.80.35.59 > > (eric@w3.org) > Feel free to forward this message to any list for any purpose other than > email address distribution. > > There are subtle nuances encoded in font variation and clever layout > which can only be seen by printing this message on high-clay paper.
Received on Tuesday, 11 November 2014 07:17:17 UTC