RE: Shapes, Individuals, and Classes - OSLC Motivations

Irene,

Your analysis of the graphs involved is correct, but I don't understand 
your statement about navigating to the shape given its type. Here is how 
OSLC handles the situation:

Graph 1 is the OSLC RDFS vocabulary document. You navigate to this by 
deferencing the type URI, e.g. oslc_cm:ChangeRequest = <
http://open-services.net/ns/cm#ChangeRequest>

Graph 2 is the OSLC Resource Shape for CM. This is linked from the spec. 
Its URI is 
http://open-services.net/pub/Main/CmSpecificationV2Shapes/oslccm-change-request-shape.xml

Graphs 3 and 4 are combined into a Resource Shape and are hosted by the 
tool that implements and extends OSLC. The OSLC Core spec defines a 
discovery mechanism that lets you find a variety of information, including 
the shapes. Basically, the tool provides a resource that contains links to 
a variety of metadata resources, e.g. http://mytool.example.com/services. 
See [1]. 

Graph 5 is an instance of a CM resource hosted by the tool, e.g. 
http://mytool.example.com/resource/42

Now suppose you want to create a new instance of a CM resource. This is 
done by POSTing an RDF representation to a URL (a creation factory). You 
can discover the URL of the creation factory by looking at the service 
provider metadata resource http://mytool.example.com/services, which also 
links to the shape (via oslc:resourceShape).

In your proposal, how do you discover the shape of the resource?

I believe the difference is that:
1) instead of oslc:ResourceShape resources, you are proposing that the 
constraints be put in an OWL/SPIN file that has the RDF type URI 
oslc_cm:ChangeRequest, as a subject node.
2) instead of oslc:resourceShape, you are proposing to use owl:import (or 
maybe another property less specific to OWL)

[1] 
http://open-services.net/bin/view/Main/OslcCoreSpecification#Service_Provider_Resources
_________________________________________________________

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, <public-data-shapes-wg@w3.org>, 
Date:   11/11/2014 08:15 PM
Subject:        RE: Shapes, Individuals, and Classes - OSLC Motivations



To be even more specific, when I look at 
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S24:_Open_Content_Model 
, everything seems fine to me until I reach:
 
?Since the shape of a resource may depend on the tool that hosts it, or 
the project that hosts it within a tool, but the RDF type of the resource 
may not depend on the tool or project, there is in general no way to 
navigate to the shape given only its RDF type.?
 
I don?t see why there is no way to navigate to the shape given only its 
RDF type. Roughly, there would be the following graphs:
 
Graph 1: Defines OSLC data model*
Graph 2: Defines OSLC data model constraints*
Graph 3: Defines tool1 (or project 1) ?custom? data model extensions**
Graph 4: Defines tool1 (or project 1) ?custom? data model constraints**
Graph 5: Data hosted by tool1 (or project1)
 
*Graph 1 and Graph 2 could be a single graph if desired
**Graph 3 and Graph 4 could be a single graph if desired
 
A union of graphs 1-4 defines tool1 (or project1) specific definition for 
the shape(s). If we add to this union graph 5 with tool 1 (project 1) 
data, we can always fetch the tool 1 (project 1) specific shape definition 
for a given type when this type is referenced in the graph 5.
 
I don?t see a need for any additional information.
 
From: Irene Polikoff [mailto:irene@topquadrant.com] 
Sent: Tuesday, November 11, 2014 5:56 PM
To: 'Arthur Ryman'; public-data-shapes-wg@w3.org
Subject: RE: Shapes, Individuals, and Classes - OSLC Motivations
 
Arthur,
 
I see RDFS as a data-modelling vocabulary for RDF data. OWL further 
extends it.
 
Quoting directly from the RDFS Specification:
 
"RDFS provides mechanisms for describing groups of related resources and 
the relationships between these resources. RDF Schema is written in RDF 
using the terms described in this document. These resources are used to 
determine characteristics of other resources, such as the domains and 
ranges of properties.
 
The RDF Schema class and property system is similar to the type systems of 
object-oriented programming languages such as Java. RDF Schema differs 
from many such systems in that instead of defining a class in terms of the 
properties its instances may have, RDF Schema describes properties in 
terms of the classes of resource to which they apply. This is the role of 
the domain and range mechanisms described in this specification. For 
example, we could define the eg:author property to have a domain of 
eg:Document and a range of eg:Person, whereas a classical object oriented 
system might typically define a class eg:Book with an attribute called 
eg:author of type eg:Person. 
 
Using the RDF approach, it is easy for others to subsequently define 
additional properties with a domain of eg:Document or a range of 
eg:Person. This can be done without the need to re-define the original 
description of these classes. One benefit of the RDF property-centric 
approach is that it allows anyone to extend the description of existing 
resources, one of the architectural principles of the Web [BERNERS-LEE98].
 
This specification does not attempt to enumerate all the possible forms of 
representing the meaning of RDF classes and properties. Instead, the RDF 
Schema strategy is to acknowledge that there are many techniques through 
which the meaning of classes and properties can be described. Richer 
vocabulary or 'ontology' languages such as OWL [OWL2-OVERVIEW], inference 
rule languages and other formalisms (for example temporal logics) will 
each contribute to our ability to capture meaningful generalizations about 
data in the Web."
 
Of course, when one describes the data model in RDFS, the statement 
"project1:customerReference rdfs:domain oslc_cm:ChangeRequest" does not 
mean that all instances of oslc_cm:ChangeRequest must have a property 
project1:customerReference. Thus, it is not a constraint as in ?must have 
this property?. However, it provides a way to identify the applicable 
properties for oslc_cm:ChangeRequest which aligns with your requirement 
?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.?
 
Cardinality aside, my main point was that there is no need to create new 
classes for this. (Although, it may be a good thing to do). 
 
If you keep the above two rdfs:domain statements in two different named 
graphs:
 
·         When the software asks a question ?what are the applicable 
properties for oslc_cm:ChangeRequest for project 1?, the answer will 
include property project1:customerReference in addition to all the 
properties defined in the OSLC since the data model for 
oslc_cm:ChangeRequest in the context of project 1 will be a union of the 
oslc_cm model graph and the custom model graph for project 1.
 
·         When this question is asked in the context of project two, the 
answer will not include project1:customerReference property, but instead 
include project2:documentationImpact property because the model for 
project 2 is described in a union of the oslc_cm model graph and the 
custom model graph for project 2.
 
If cardinality needs to me expressed, then one could use OWL or a SPIN 
constraint. The named graphs and the model unions described above apply in 
the same way.
 
Regards,
 
Irene
 
 
 
-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Tuesday, November 11, 2014 4:30 PM
To: public-data-shapes-wg@w3.org
Subject: RE: Shapes, Individuals, and Classes - OSLC Motivations
 
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.
 
_________________________________________________________
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
>> 
>> 
> 
> 
>

Received on Wednesday, 12 November 2014 18:47:04 UTC