[oslc-core] OSLC resources with multiple types - scenarios where rdf:type does not always fit
Arthur Ryman
ryman at ca.ibm.com
Mon Mar 26 17:01:39 EDT 2012
Steve,
I replied to this proposal elsewhere. However, I'd like to establish some
principles for using XML.
1. If you are using XML to represent RDF then the content type MUST be
application/rdf+xml and any valid RDF/XML MUST be acceptable.
2. If you are using plain old XML, then the content type MUST be
application/xml or application/<mytype>+xml where <mytype> is a
well-specified XML subtype. In either case the domain spec should
precisely define the acceptable document content, e.g. using an XSD or
DTD. If this format is supposed to be an equivalent to or an alternative
for RDF then the domain spec should precisely define how it maps to RDF,
i.e. for a given XML document, define precisely the corresponding set of
RDF triples.
Regards,
___________________________________________________________________________
Arthur Ryman
DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
From:
Steve K Speicher <sspeiche at us.ibm.com>
To:
oslc-core at open-services.net
Date:
03/21/2012 05:59 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
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
>
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list