- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 10 Nov 2014 07:54:20 -0800
- To: Arthur Ryman <ryman@ca.ibm.com>, Eric Prud'hommeaux <eric@w3.org>
- CC: public-data-shapes-wg@w3.org
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 Monday, 10 November 2014 15:54:50 UTC