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

[Steve K Speicher]

Summarizing the discussion from the meeting from today and some of my own 
thoughts.

The issue of the XML format and multi-type resources seems real, 
especially with toolkits like Jena that don't roundtrip it consistently.

The question is what class of clients and servers need both 
application/xml format (not application/rdf+xml) as well as multi-type 
resources? 
A1. Some clients may need to use XML as they can only process XML due to 
constrains such as browsers, etc. 
In this case you'd assume the browser would prefer JSON, which handles 
this fine. 
There are a number of JavaScript libs for handling RDF/XML (no experience 
with them)

A2. Some servers prefer consuming application/xml and emitting it.
We haven't run into many of these servers.

So in my opinion, we should document this as a limited of the 
application/xml format and state that implementations should "expect 
either" (starting to sound like a RDF/XML parser).

We agreed to do a bit more investigation on a variety of fronts, such as 
can we fixup Jena using OSLC-Abbrev writer we have to be more predictable. 
  Results to follow.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


> From: Michael F Fiedler/Durham/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 03/20/2012 08:56 PM
> Subject: Re: [oslc-core] OSLC resources with multiple types - scenarios 
> where rdf:type does not always fit
> Sent by: oslc-core-bounces at open-services.net
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>