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

[Michael F Fiedler]

Correction to the types in the example - overzealous copy/paste

Regards,
Mike




                                                                           
             Michael F                                                     
             Fiedler/Durham/IB                                             
             M at IBMUS                                                    To 
             Sent by:                  oslc-core at open-services.net,        
             oslc-core-bounces                                          cc 
             @open-services.ne                                             
             t                                                     Subject 
                                       [oslc-core] OSLC resources with     
                                       multiple types - scenarios where    
             03/20/2012 04:19          rdf:type does not always fit        
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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://example.org/ns/my_ns#Application"/>
</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://open-services.net/ns/asset#Asset"/>
</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