Re: Shapes, Individuals, and Classes - OSLC Motivations

Peter,

I disagree with your assertion that "1"^^xsd:integer and "01"^^xsd:integer 
represent different RDF nodes. Please refer to [1] and [2] 

A datatype consists of a lexical space, and value space, and a 
lexical-to-value mapping. Several strings in the lexical space may map to 
the same element of the value space.  An RDF literal that includes a 
datatype URI represents the value, i.e. the lexical-to-value mapping is 
applied to the lexical string.

[1] http://www.w3.org/TR/rdf11-concepts/#section-Datatypes
[2] http://www.w3.org/TR/rdf11-mt/#literals-and-datatypes
_________________________________________________________
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, "Eric Prud'hommeaux" 
<eric@w3.org>, 
Cc:     public-data-shapes-wg@w3.org
Date:   11/10/2014 10:54 AM
Subject:        Re: Shapes, Individuals, and Classes - OSLC Motivations



RDF graphs are defined without respect to XML datatypes.  For example, 
"1"^^^xsd:integer and "01"^^xsd:integer are different as far as RDF graphs 
are 
concerned.

Of course, there is a close relationship between these two literals, but 
that 
is (mostly) defined in the RDF semantics.

So is it then the case that OSLC goes beyond RDF graphs?

peter


On 11/10/2014 07:38 AM, Arthur Ryman wrote:
> Eric,
>
> Yes. RDF includes the built-in XML datatypes.
> _________________________________________________________
> Arthur Ryman
> Chief Data Officer
> SWG | Rational
> 905.413.3077 (phone) | 416.939.5063 (cell)
> IBM InterConnect 2015
>
>
>
>
> From:   "Eric Prud'hommeaux" <eric@w3.org>
> To:     "Peter F. Patel-Schneider" <pfpschneider@gmail.com>,
> Cc:     Arthur Ryman/Toronto/IBM@IBMCA, public-data-shapes-wg@w3.org
> Date:   11/07/2014 08:46 AM
> Subject:        Re: Shapes, Individuals, and Classes - OSLC Motivations
>
>
>
> * 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 Tuesday, 11 November 2014 22:00:35 UTC