RE: Shapes, Individuals, and Classes - OSLC Motivations

Eric,

Exactly, and OSLC does in fact reuse DC terms as much as possible.
_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015


"Eric Prud'hommeaux" <eric@w3.org> wrote on 11/11/2014 04:59:35 PM:

> From: "Eric Prud'hommeaux" <eric@w3.org>
> To: Arthur Ryman/Toronto/IBM@IBMCA, 
> Cc: public-data-shapes-wg@w3.org
> Date: 11/11/2014 04:59 PM
> Subject: 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 22:15:39 UTC