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
