Re: Shapes, Individuals, and Classes - OSLC Motivations

It appears to me that all the proposals, with the possible exception of ShEx, 
are based on RDF graphs, so I don't expect that you will get much pushback on 
your statement as written.

It's more likely that exclusion will be the problem.

peter


On 11/12/2014 05:45 AM, Arthur Ryman wrote:
> Peter,
>
> Yes, we should consider all proposals.
>
> This discussion was valuable for me since it helped me understand the
> nuances of RDF graphs. I believe we agree now that basing the semantics of
> constraints on RDF graphs is viable, provided that we are precise about
> how literal nodes are handled. The semantics of literal nodes and
> datatypes is covered by the core RDF specs.
> _________________________________________________________
> 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:     "Eric Prud'hommeaux" <eric@w3.org>, public-data-shapes-wg@w3.org
> Date:   11/12/2014 08:14 AM
> Subject:        Re: Shapes, Individuals, and Classes - OSLC Motivations
>
>
>
> Yes, the working group could take this approach to define the semantics of
>
> constraints, but there are other approaches that I believe are at least as
> viable.
>
> peter
>
>
> On 11/12/2014 04:59 AM, Arthur Ryman wrote:
>> Peter,
>>
>> You are right. I reread the spec more carefully. A literal term contains
>> the lexical form, not the value defined by the lexical-to-value mapping.
>> Literal term equality requires that the lexical forms are equal,
>> character-by-character.
>>
>> The consequence of this is that when we define the semantics of
>> constraints we should phrase them in terms of the value space of the
>> associated datatype, if that is significant. If we translate constraints
>> into SPARQL then we should use the appropriate type-casting functions.
>>
>> Therefore we can still define the semantics of constraints in terms of
> the
>> RDF graph, but we need to be explicit about when we are referring to the
>> value space of a datatype.
>> _________________________________________________________
>> 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:     "Eric Prud'hommeaux" <eric@w3.org>, public-data-shapes-wg@w3.org
>> Date:   11/11/2014 07:59 PM
>> Subject:        Re: Shapes, Individuals, and Classes - OSLC Motivations
>>
>>
>>
>> You can disagree all you want, but "1"^^xsd:integer and
> "01"^^xsd:integer
>> do
>> indeed represent different nodes in any RDF graph.  To see this all you
>> have
>> to look at is the RDF Concepts and Abstract Syntax
>> http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/ Section 3.3,
> which
>> talks about literal term equality, and Section 3.1, which says that the
>> triples of RDF objects can be literals.
>>
>> Neither datatypes nor the RDF model theory nor what an RDF literal
>> represents
>> affect this aspect of RDF graphs.
>>
>> peter
>>
>>
>>
>> On 11/11/2014 02:00 PM, Arthur Ryman wrote:
>>> 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 Wednesday, 12 November 2014 22:23:18 UTC