[oslc-core] Some Topics for Discussion Today

Arthur Ryman ryman at ca.ibm.com
Mon May 31 11:06:57 EDT 2010


Thx for the attachment. I read it. The title talks about "Type Systems". 
As you point out, in RDF, the "type" is just another property and 
resources may have many types. If we want some resource to be used in 
another context, we can add another rdf:type property, in addition to 
whatever other properties the resource acquires in the new context, RDFS 
and OWL let you infer the type based on the properties, but we don't need 
to rely on that.

In the case of Shape resources, we are really talking about resource 
descriptions, not specific resource instances, e.g. so we know what 
properties to query on or to use for creation. Shape resources are a 
simple and very explicit way to represent that info, however, they do 
duplicate some capabilities of OWL. We don't want to force spec readers or 
implementations to understand OWL. However, we could regard Shape 
resources as a kind of syntactic sugar for OWL.

So I agree with your observation that OWL can describe Shapes. I think we 
can use OWL in the background as a guide on our Shape resources, i.e. 
let's at least be consistent with OWL where we overlap.

BTW, I noticed a problem in your paper. In the following example you use 
owl:equivalentClass, but I think you should use rdfs:subClassOf:

<owl:Class rdf:about="#PotentialPlanItem">
                <owl:onProperty rdf:resource="#enddate"/>
                <owl:someValuesFrom rdf:resource="#Date"/>
                <owl:onProperty rdf:resource="#estimatedeffort"/>
                <owl:someValuesFrom rdf:resource="#float"/>
        <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing

The intension is that PotentialPlanItem has both an enddate and an 
estimatedeffort, i.e. it lies of the intersection of the restriction 
classes defined by either property.


Arthur Ryman, PhD, DE

Chief Architect, Project and Portfolio Management

IBM Software, Rational

Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube

Ian Green1 <ian.green at uk.ibm.com>
Arthur Ryman/Toronto/IBM at IBMCA
oslc-core at open-services.net, oslc-core-bounces at open-services.net
05/27/2010 10:51 AM
Re: [oslc-core] Some Topics for Discussion Today

Hi Arthur
some of my OWL thinking can be found in the attached document.  perhaps it 

would provoke a discussion?  (The "OWL" parts in the attached document - 
Simon nor Ed commented on that so they may not agree with what I wrote.)

You suggestion that we could offer a mapping to OWL is not something I'd 
considered, but would offer a way to put shape on a firmer basis without 
pulling in the complexity of the underlying RDF model.  It would also 
finesse the intractability of OWL DL.  I'm not sure that it would lead to 
a common understanding of the meaning of the OSLC resource shape 

best wishes,

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational

oslc-core-bounces at open-services.net wrote on 26/05/2010 13:59:42:

> [image removed] 
> [oslc-core] Some Topics for Discussion Today
> Arthur Ryman 
> to:
> oslc-core
> 26/05/2010 14:00
> Sent by:
> oslc-core-bounces at open-services.net
> 1. I've been digging deeper into OWL and there does appear to be a way 
> express the kind of information we are putting in our Shape resources, 
> e.g. cardinality. The OWL way is somewhat more complex - it involves 
> restrictions. Our Shape approach is easier for clients to handle. I 
> we should at least describe the semantics of Shape in terms of OWL so we 

> are compatible. We may be able to regard Shape as a simplified form for 
> the equivalent OWL.
> 2. Our use of Dublin Core namespace prefixes seems a little inconsistent 

> with common practice. We are using the newer terms namespace, 
> http://purl.org/dc/terms/ instead of the legacy elements namespace
> http://purl.org/dc/elements/1.1/. However, the usual prefix for the 
> namespace seems to be dcterms: while the elements namespace uses dc:.  I 

> suggest we adopt this convention and use dcterms: as the predefined and 
> recommended prefix. See [1]
> "So as not to affect the conformance of existing implementations of 
> "simple Dublin Core" in RDF, domains and ranges have not been specified 
> for the fifteen properties of the dc: namespace 
> (http://purl.org/dc/elements/1.1/). Rather, fifteen new properties with 
> "names" identical to those of DCMES Version 1.1 have been created in the 

> dcterms: namespace (http://purl.org/dc/terms/). "
> 3. I think we should establish or identify a best practice for services 
> that provide access to resources through both http and https. In this 
> case, the same resource is being made available at two different URLs. 
> resource should have one preferred URI which appears in the resource 
> representations, is used for links, etc. If we don't establish a 
> URI then queries, etc. could get complex. Anyone have experience with 
> situation?
> [1] http://dublincore.org/documents/dcmi-terms/
> Regards, 

> Arthur Ryman, PhD, DE
> Chief Architect, Project and Portfolio Management
> IBM Software, Rational
> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
> Twitter | Facebook | YouTube
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
A non-text attachment was scrubbed...
Name: JFS Type Model.odt
Type: application/octet-stream
Size: 18808 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100531/714ab816/attachment.odt>

More information about the Oslc-Core mailing list