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
>>
>>
>
>
>

Received on Thursday, 6 November 2014 21:25:54 UTC