Mike, I am strongly opposed to this recommendation since it attempts to prolong the use of plain old XML as a valid alternative to RDF. In the early days of OSLC we tried to disguise RDF as XML. I am guilty of advocating that policy because I thought our stakeholders were not ready to abandon XML and embrace RDF. The result was that we introduced terms and concepts that obscured the underlying RDF basis of OSLC. In hindsight, we should have used standard RDF terms and concepts. The industry has matured and now RDF is more mainstream so it's time we simplified our message and reject the XML disguise.
The most useful way to think of OSLC is that it is not just about REST services, in which case XML would be a valid resource representation, but instead, OSLC is about Linked Data applied to software and systems development. We use the term Linked Lifecycle Data to describe this combination. In the Linked Data world, services provide RDF representations. You can serialize RDF as XML, Turtle, JSON, or even embed it in HTML via RDFa. The only reliable way to process RDF is with an RDF toolkit. Jena can generate both abbreviated and non-abbreviated RDF. However, there is no reliable way to process abbreviated RDF/XML using other XML processors due to the large number of optional and alternate abbreviations. The simplest way to process RDF/XML as XML, e.g. with XSLT or XPATH, is to use non-abbreviated XML, in which case there is no disguise. You use <rdf:Description> to introduce subject nodes. Regards, ___________________________________________________________________________ Arthur Ryman DE, PPM & Reporting Chief Architect IBM Software, Rational Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) From: Michael F Fiedler <[email protected]> To: [email protected] Date: 03/20/2012 04:23 PM Subject: [oslc-core] OSLC resources with multiple types - scenarios where rdf:type does not always fit Sent by: [email protected] In the Asset and Automation (perhaps others) specifications there is a need for resources to have multiple type predicates. This is also common in general RDF resource representations. In an OSLC context, it is sometimes desirable to give one of these types primacy. One scenario where this is true is when consumers request application or abbreviated XML instead of RDF XML via an application/xml Accept header. Example: <oslc_asset:Asset rdf:about="http://example.org/assets/1";> <dcterms:title>My Application</dcterms:title> <rdf:type rdf:resource="http://open-services.net/ns/asset#Asset"/> </oslc_asset:Asset> gives a graph equivalent to <my_ns:Application rdf:about="http://example.org/assets/1";> <dcterms:title>My Application</dcterms:title> <rdf:type rdf:resource="http://example.org/ns/my_ns#Application"/> </my_ns:Application> For an Accept header of application/rdf+xml, the requester must be able to handle either representation. Low-end consumers (browsers, scripts with no RDF parser, etc) can request application/xml to get an XML representation of the resource which is consistent with the RDF/XML representation. The OSLC Core Representation Guidance [1] states that this XML representation is appropriate where the "use of RDF/XML toolkits is not appropriate or preferred." Without an RDF toolkit, a consumer who is parsing responses as XML rather than RDF (XPath query, etc) must do additional work to query for the subject in the graphs above. The Core guidance does not promote any particular library for generating application/xml representations of resources, but many provider implementations (commercial and open source) are using the Apache Jena library's abbreviated RDF XML representation when consumers request application/xml. Jena does not provide a way to manipulate the abbreviated RDF XML format and from an XML consumer's point of view, assigns type type of the resource node "randomly". OSLC Core does not say anything about deterministically "hardening" the XML node types when the representation is application/xml, but some consumers may benefit from it. A second scenario is one where the "primary" resource type is the OSLC resource type and the "secondary" type is a type in a non-OSLC domain (similar to the examples above). There's a different meaning for the types at some level. In some specifications, dcterms:type has been used (provisionally) for "secondary" types and rdf:type for the "primary" type desired on the XML nodes for application/xml. This lets Jena (or other serializers) pick the "right" type. However, Dublin Core's guidance [2] prefers using rdf:type over dcterms:type in RDF contexts since RDF processors have built-in knowledge of rdf:type. One possibility is to introduce an oslc:type/oslc:additionalType property for use in this scenario. From an RDF perspective, this feels artificial (and perhaps counter-productive when rdf:type is the right fit), but it is a possible solution for the non-RDF consumer. Comments? I'd like suggest this as a topic at the next Core meeting, but on-list discussion would be beneficial as well. [1] - open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations#Guidelines_for_application_xml [2] - http://dublincore.org/documents/dc-rdf/#sect-5 Regards, Mike _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
