Re: Shapes, Individuals, and Classes - OSLC Motivations

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 15:39:26 UTC