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

Arthur Ryman ryman at ca.ibm.com
Wed May 30 14:16:08 EDT 2012


John,

One problem is that oslc:valueType is defined for use in resource shapes. 
It is associated with how a predicate is used within resource graph. If 
you use it directly on the predicate, then that would imply a constraint 
for any resource graph. We'd have to spell that out. 

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:
John Arwe <johnarwe at us.ibm.com>
To:
oslc-core at open-services.net
Date:
05/24/2012 08:36 AM
Subject:
Re: [oslc-core] Expressing oslc:valueType and/or oslc:range     within 
RDFS
Sent by:
oslc-core-bounces at open-services.net



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

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







More information about the Oslc-Core mailing list