[oslc-core] OSLC resources with multiple types - scenarios where rdf:type does not always fit
ryman at ca.ibm.com
Mon Mar 26 12:19:38 EDT 2012
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
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.
DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
Michael F Fiedler <fiedler at us.ibm.com>
oslc-core at open-services.net
03/20/2012 04:23 PM
[oslc-core] OSLC resources with multiple types - scenarios where rdf:type
does not always fit
oslc-core-bounces at open-services.net
In the Asset and Automation (perhaps others) specifications there is a
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.
gives a graph equivalent to
For an Accept header of application/rdf+xml, the requester must be able to
handle either representation. Low-end consumers (browsers, scripts with
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  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
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
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
"right" type. However, Dublin Core's guidance  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.
I'd like suggest this as a topic at the next Core meeting, but on-list
discussion would be beneficial as well.
 - http://dublincore.org/documents/dc-rdf/#sect-5
Oslc-Core mailing list
Oslc-Core at open-services.net
More information about the Oslc-Core