Re: SPARQL equivalence semantics

* 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)


> 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 Monday, 10 November 2014 17:55:52 UTC