[oslc-core] Some Topics for Discussion Today

Ian Green1 ian.green at uk.ibm.com
Thu May 27 10:51:43 EDT 2010

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/20100527/b8964c2b/attachment-0001.odt>

More information about the Oslc-Core mailing list