RE: Shapes, Individuals, and Classes - OSLC Motivations

Arthur, this is very helpful. 

Could you update the web page describing your scenario with this
information? I would not want us to lose it in e-mails.

Thanks,

Irene

-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Wednesday, November 12, 2014 1:47 PM
To: Irene Polikoff
Cc: public-data-shapes-wg@w3.org
Subject: 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-requ
est-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_Provide
r_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_Mode
l
, 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 19:01:32 UTC