RE: Shapes, Individuals, and Classes - OSLC Motivations

* Arthur Ryman <ryman@ca.ibm.com> [2014-11-11 16:29-0500]
> Irene,
> 
> The triple "project1:customerReference rdfs:domain oslc_cm:ChangeRequest" 
> is not a constraint. It is an inference rule that states if you have a 
> triple "X project1:customerReference Y" then you can infer a triple "X 
> rdf:tytpe oslc_cm:ChangeRequest".
> 
> What we want in the OSLC use case is for the web application that hosts 
> the resources that belong to project1 to advertise the fact there is a new 
> property "project1:customerReference", which is an extension to the OSLC 
> CM specification. This is allowed by the OSLC CM specification since it 
> specifies an open content model. A resource of type oslc_cm:ChangeRequest 
> is allowed to have properties not defined by the OSLC CM specification.
> 
> OSLC adopts the design principles of Linked Data. Roughly, this is REST + 
> RDF. OSLC does not depend on RDFS or OWL terms that require inferencing. 
> OSLC does provide vocabulary documents using RDFS and OWL annotation 
> terms. A compliant OSLC implementation does not require an RDFS or OWL 
> reasoner. This choice was made in order to lower the implementation burden 
> for existing web applications to provide Linked Data interfaces. 
> 
> As far as OSLC is concerned, rdf:type is simply another property. It has 
> no OO connotations. The RDF representation of an HTTP resource is simply a 
> set of triples. The URI of the resource itself will normally be the 
> subject node of many of the triples and it will normally have one or more 
> rdf:type triples.
> 
> In the world of Linked Data, it does not make sense for project 1 to have 
> its own definition of oslc_cm:ChangeRequest since oslc_cm:ChangeRequest is 
> a URI that belongs to the OSLC URI space. To get authoritative information 
> about oslc_cm:ChangeRequest, you do an HTTP GET on it. That request will 
> return its RDFS vocabulary document, which is hosted on the OSLC server. 
> OSLC defines the meaning of the terms in its URI space. Other applications 
> are encouraged to reuse those terms if their use is consistent with the 
> OSLC definition. In order to make terms widely reusable, OSLC avoids this 
> use of RDFS terms such as rdfs:domain and rdfs:range since they may entail 
> undesired inferences.

Dublin Core uses a similar strategy to optimize for reusability.
This is effective in that many other systems and ontologies use
e.g. dc:author, but it means that an individual system using dc:author
will have to further constrain what it expects in the object position.


> _________________________________________________________
> Arthur Ryman
> Chief Data Officer
> SWG | Rational
> 905.413.3077 (phone) | 416.939.5063 (cell)
> IBM InterConnect 2015
> 
> 
> 
> 
> From:   "Irene Polikoff" <irene@topquadrant.com>
> To:     Arthur Ryman/Toronto/IBM@IBMCA, "'Peter F. Patel-Schneider'" 
> <pfpschneider@gmail.com>, 
> Cc:     <public-data-shapes-wg@w3.org>
> Date:   11/06/2014 05:43 PM
> Subject:        RE: Shapes, Individuals, and Classes - OSLC Motivations
> 
> 
> 
> Sorry, I meant project1:customerReference rdfs:domain 
> oslc_cm:ChangeRequest
> 
> -----Original Message-----
> From: Irene Polikoff [mailto:irene@topquadrant.com] 
> Sent: Thursday, November 06, 2014 4:25 PM
> To: 'Arthur Ryman'; 'Peter F. Patel-Schneider'
> Cc: public-data-shapes-wg@w3.org
> Subject: RE: Shapes, Individuals, and Classes - OSLC Motivations
> 
> < For example, one project might add a customer reference number while
> another might add a boolean flag indicating if there is an impact to the
> online documentation. These custom attributes also appear as additional 
> RDF
> properties of the resources.
> 
> OSLC specifications typically define one or more RDF types. For example, 
> the
> RDF type for change requests is oslc_cm:ChangeRequest where the prefix
> oslc_cm is <http://open-services.net/ns/cm#>. The RDF representation of an
> OSLC change request contains a triple that defines its type as
> oslc_cm:ChangeRequest, triples that define RDF properties as described in
> the OSLC CM specification, and additional triples that correspond to
> tool-specific or project-specific custom attributes. 
> 
> Note that the addition of custom attributes does not require the 
> definition
> of a new RDF type. Furthermore the RDF properties used to represent custom
> attributes may come from any RDF vocabulary. In fact, tool administrators
> are encouraged to reuse existing RDF properties rather than define
> synonyms.>
> 
> Then, members of oslc_cm:ChangeRequest for project 1 must have a property
> project1:customerReference and for project2, members of this class have a
> property project2:documentationImpact.
> 
> Such extensions of some core ontology(s) are pretty common. One may decide
> to create a project1:ChangeRequest class for this or simply add a triple
> oslc_cm:ChangeRequest rdfs:domain project1:customerReference to the graph
> that contains the ontology used for project 1. Which of these approaches 
> to
> use is a matter of preference/implementation.
> 
> I do not see a problem or any special requirement here. It is "business as
> usual". Am I missing something?
> 
> Irene
> 
> -----Original Message-----
> From: Arthur Ryman [mailto:ryman@ca.ibm.com]
> Sent: Thursday, November 06, 2014 3:02 PM
> To: Peter F. Patel-Schneider
> Cc: public-data-shapes-wg@w3.org
> Subject: Re: Shapes, Individuals, and Classes - OSLC Motivations
> 
> Peter,
> 
> I've created a user story [1] that describes "custom attributes" and 
> related
> concepts. These concepts were not created by OSLC. Rather, OSLC was 
> designed
> to accommodate this situation which is very common in software development
> tools and probably many other applications.
> 
> For example, consider GMail Contacts. It defines several types of phone
> number (home, work, mobile), address (home, work), etc, but you can add
> custom types. You'd probably start with vCard as the RDF representation. 
> Now suppose your company was using GMail, and that you could configure it
> with some additional types of phone number, and could specify the RDF
> property for those.
> 
> [1]
> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S24:_Open_Content_Mode
> 
> l
> _________________________________________________________
> 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
> >>
> >>
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Tuesday, 11 November 2014 21:59:40 UTC