Re: Shapes, Individuals, and Classes - OSLC Motivations

RDF graphs, as far as the W3C is concerned, are defined in 
http://www.w3.org/TR/rdf11-concepts/.  To be based on RDF graphs means at 
least to be equivalent to (preferably to use) the definitions from there, 
either directly or indirectly.   As most of the various proposals are built on 
W3C recommendations that build on RDF they (should) qualify.

The meaning of ShEx is defined in terms of Z and appears to have a parallel 
definition of RDF graphs.  This would have to be investigated to determine 
whether it conforms to the W3C definition of RDF graphs.

peter


On 11/12/2014 11:00 PM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-12 14:22-0800]
>> 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.
>
> "based on RDF graphs" might mean:
>    1 uses the RDF datamodel for unifying terms
>    2 expressable in RDF
>    3 syntactic support for (simultaneous) named graphs
>
> ShEx is an extension to Resource Shapes to provide OR and semantic
> actions (extensibility). ShExC is a compact syntax of ShEx. Arthur's
> email suggests he was talking about 1. Can you explain why ShEx
> wouldn't be "based on RDF graphs"?
>
>
>> 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 Thursday, 13 November 2014 14:07:15 UTC