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 <[email protected]> To: Steve K Speicher/Raleigh/IBM@IBMUS Cc: [email protected], [email protected] Date: 05/23/2012 10:38 PM Subject: Re: [oslc-core] Expressing oslc:valueType and/or oslc:range within RDFS Sent by: [email protected] 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 _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
