[oslc-core] OSLC resources with multiple types - scenarios where rdf:type does not always fit

[Arthur Ryman]

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 <fiedler at us.ibm.com>
To:
oslc-core at open-services.net
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:
oslc-core-bounces at open-services.net




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
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net