[oslc-core] Expressing oslc:valueType and/or oslc:range within RDFS

Thu May 24 08:34:54 EDT 2012

I had a sense on the call that you guys were talking past one another, and 
now it's deja vu all over again.
The key is probably your question (from the call) "do you [Steve] mean RDF 
annotations?".
I wasn't sure what those were (well-defined &something vs term of art) at 
the time; after some brief research, I think the answer is "yes".
One example: when defining the RDFS document for an OSLC vocabulary, we 
could just stick an oslc:valueType predicate inside the property 
definition (assuming the syntax allows it, but I expect so this is RDF 
after all and it's "just another triple").
Fair to say we cannot do so for vocabulary we do not control, but they 
would not appear in our vocabulary documents anyway.  The resource 
definition table would be the only obvious place we could constrain 
something like dcterms:created to be an xs:dateTime vs Dublin Core's 
rdfs:Literal range.
I think we did agree on the call that using Range in our own RDFS was 
inappropriate, precisely for the reasons you articulate.  oslc:valueType 
is a predicate we control, and a generic RDFS processor therefore will 
infer no additional triples unless we license it to do so.  Or am I 
missing something?

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

From:   Arthur Ryman <ryman at ca.ibm.com>
To:     Steve K Speicher/Raleigh/IBM at IBMUS
Cc:     oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:   05/23/2012 10:38 PM
Subject:        Re: [oslc-core] Expressing oslc:valueType and/or 
oslc:range within       RDFS
Sent by:        oslc-core-bounces at open-services.net

Steve,

I commented on this on a recent telecon. In summary:

1. RDFS and OWL are inference languages. They define rules for deriving 
new triples from given triples. This is not what we mean when we indicate 
the value type of a predicate.

2. Our tables document how predicates are used within a resource (or more 
narrow context such as resource creation). This applies to predicates we 
define or reuse, e.g. Dublin Core, FOAF. These are constraints on what 
constitutes a valid RDF representation of a resource. These constraints 
cannot be part of the vocabulary since we do not control Dublin Core or 
FOAF. That is why we introduced ResourceShapes. 

One technical nit - RDF terms are not QNames, they are URIs. A QName is a 
pair (namespace URI, local name). Syntactically a QName looks like a CURIE 

(Compact URI), but they mean something different. RDF/XML conflates these.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational 

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 

From:
Steve K Speicher <sspeiche at us.ibm.com>
To:
oslc-core at open-services.net
Date:
05/16/2012 09:54 AM
Subject:
[oslc-core] Expressing oslc:valueType and/or oslc:range within RDFS
Sent by:
oslc-core-bounces at open-services.net

In thinking about best to define our vocabularies in a reusable way across 

other domains within OSLC and beyond, I think it would be good to be able 
to define each vocabulary term as:
Predicate QName -- Value Type QName -- Meaningful description string -- 
Some indication of its maturity [stable | learning | proposed]
It would also be desirable to use a normative way to express these 
vocabularies with RDF Schema/OWL or OSLC Resource Shapes. Then derive our 
human-readable versions from them (like we do today) and provide 
scenario-specific constraints such as read-only and occurs.

Take for example what we have in Core Common Properties [1] and Linked 
Data Basic Profile [2], it follows this pattern mostly.  With [1] we have 
some extra details and with [2] we possibly lump value types within the 
Range heading, implying rdfs:range perhaps wrongly.

It appears that RDFS doesn't provide a great way to indicate "Value Type 
QName" and need to determine if OWL plays a role here.  The usage of 
rdfs:range is limited to rdfs:Classes, so things like xsd:String are not a 

rdfs:Class.
So to better "explain" the common or expected value type, I'm suggesting 
we just reuse oslc:valueType within our RDFSs.  The valid choices for 
oslc:valueType will be same as defined in current Core V2 spec + 
rdf:Resource.
Additionally, we would create a predicate to indicate the term's maturity 
or use a recommended one.

Any feedback on this approach?  Suggestions on a better mechanism?

I looked around [3] for some best practices on this and appears to be a 
bit spotty on the usage, other than just simply a local defined rdfs:range 

object or using rdfs:Literal.

[1] - http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] - http://www.w3.org/Submission/ldbp/#bpr-prop
[3] - http://dublincore.org/schemas/rdfs/

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120524/9b6e02c2/attachment-0003.html>