Re: SPARQL equivalence semantics

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.

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

Received on Monday, 10 November 2014 17:53:11 UTC