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

[Arthur Ryman]

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