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 <[email protected]> To: [email protected] Date: 05/16/2012 09:54 AM Subject: [oslc-core] Expressing oslc:valueType and/or oslc:range within RDFS Sent by: [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
