PROV-AQ - format of returned provenance information

All,

Currently the PROV-AQ document requires that a provenance service is capable of 
returning provenance information as RDF 
(http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html#provenance-service-invocation)

In recent discussion with Paul, we identified a number of alternative 
possibilities, covering a spectrum of trade-offs between implementer choice and 
interoperability:

(a) no required format, possibly with light recommendation for RDF
(b) require servers to support all standard formats through content negotiation
(c) require clients to accept all formats
(d) require server to support one preferred format,
     with others optional through content negotiation

Currently, the spec sits somewhere between (a) and (d), with the required format 
being RDF (in any of its recognized serializations).

...

My thoughts on the options:

(a) this doesn't provide any guarantee of interoperability between a conforming 
client and server.  But it could be our best option until we get a better view 
on what formats for provenance developers actually use in practice.  Given this 
is a NOTE, a kind of experimental protocol, that's less harmful than it would be 
in a full REC.

(b) For some value of "standard formats".  I fear this could put undue burden on 
servers required to support multiple formats for which there is no available 
library support - depending on what are considered to be standard formats. 
(Compare with any standard RDF format, where miost RDF libraries have in-built 
support for the various serializations of RDF)

(c) I think this places an unacceptable burden on clients, which I assume will 
be relatively lightweight on average.

(d) This is the traditional approach to ensure interoperability.  But it does 
require that we can agree on a single required format, and it does constrain 
client implementations.

#g
--


See also: http://www.w3.org/2011/prov/track/issues/428

Tracker, this is issue 428

Received on Tuesday, 20 November 2012 12:40:33 UTC