ISSUE-425: Why does the service description need to be rdf?

My short answer to this is: because it's easiest to specify. I think we already pulled back somewhat from describing multiple formats in other contexts.

A slightly longer answer is: this isn't a closed specification. It's not even normative. There's nothing in this document that prevents use of some other format selected using content negotiation.

Section 4.3 already suggests use of content negotiation to select an RDF format. I'd suggest adding an additional sentence in this section along the lines of "While use of RDF for service descriptions is a recommended option, this specification does not preclude the use of non-RDF formats that a service may choose to offer, and which can be selected using HTTP content negotation"

I've added text as suggested, and offer it for review (when the document is pushed back to the W3C repo)

Open discussion with LDP group about their thoughts for a service document format for REST API resource discovery ala service document. (Also mention Mark Nottingham's JSON proposal in IETF.)

Soften the text so that it's more like a recommendation that a requirement (for now, at least).

https://www.w3.org/2011/prov/track/issues/434 merges with this.

Email sent to prov-wg and ldp lists:
http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0036.html
http://lists.w3.org/Archives/Public/public-prov-wg/2012Nov/0186.html

Responses from LDP indicate that it's something they'll consider, but don't yet have a position. Proposing to leave text as is, but have added a note drawing attention to the LDP activity and recommending that developers follow consensus that may emerge.

See: http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html#provenance-service-description

See also:
http://lists.w3.org/Archives/Public/public-prov-wg/2012Nov/0325.html

which is in response to a related point raised by Tim.

Re-opening in response to comments by Ivan and Stian. We need to form a clear consensus about what we'll recommend, and what (if anything) we'll require.

See also: https://www.w3.org/2011/prov/track/issues/622

The latest version of the spec adopts a fairly liberal position in that the service description may be in any format selectable by content negotiation, but only RDF-based formats are defined by this note, and standardized content-types are redcommended. I think this leaves the way open for XML-based services without getting into details of specifying them, which is consistent with the generally format-independent stance of PROV-AQ.

Propose to close with no further change.