Re: Shapes, Individuals, and Classes - OSLC Motivations

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?

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 16:14:10 UTC