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" < <mailto:irene@topquadrant.com>
irene@topquadrant.com>

To:     Arthur Ryman/Toronto/IBM@IBMCA, "'Peter F. Patel-Schneider'" 

< <mailto:pfpschneider@gmail.com> pfpschneider@gmail.com>, 

Cc:     < <mailto:public-data-shapes-wg@w3.org>
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>
mailto:irene@topquadrant.com]

Sent: Thursday, November 06, 2014 4:25 PM

To: 'Arthur Ryman'; 'Peter F. Patel-Schneider'

Cc:  <mailto:public-data-shapes-wg@w3.org> 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#>
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> mailto:ryman@ca.ibm.com]

Sent: Thursday, November 06, 2014 3:02 PM

To: Peter F. Patel-Schneider

Cc:  <mailto:public-data-shapes-wg@w3.org> 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_Mod
e>
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" < <mailto:pfpschneider@gmail.com>
pfpschneider@gmail.com>

To:     Arthur Ryman/Toronto/IBM@IBMCA, 

Cc:      <mailto:public-data-shapes-wg@w3.org> 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" < <mailto:pfpschneider@gmail.com>
pfpschneider@gmail.com>

> To:     Arthur Ryman/Toronto/IBM@IBMCA,
<mailto:public-data-shapes-wg@w3.org> 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

>> 

>> 

> 

> 

>