W3C home > Mailing lists > Public > public-grddl-comments@w3.org > April to June 2007

RE: Comments on GRDDL draft [OK?] (#issue-output-formats)

From: Dan Connolly <connolly@w3.org>
Date: Mon, 30 Apr 2007 09:50:49 -0500
To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
Cc: public-grddl-comments@w3.org
Message-Id: <1177944649.13028.78.camel@dirk>

On Mon, 2007-04-30 at 03:28 -0400, Booth, David (HP Software - Boston)
> > This is... issue-output-formats: whether GRDDL
> > transformations may produce RDF in a format other than
> > RDF/XML.
> > RESOLUTION: to resolve issue-output-formats by (1) adding formal rules
> > to cover the case of of the XSLT 1.0 and RDF/XML (2) to
> > allow other output formats as exemplified by the
> > Atom/turtle test case
> > http://www.w3.org/2004/01/rdxh/spec#issue-output-formats
> > ->
> >  http://www.w3.org/2001/sw/grddl-wg/td/grddl-tests#atomttl1
> >
> > So yes, a transformation may specify its output using
> > turtle, but no, there is no mechanism for an agent to
> > indicate which output formats it wants the transformation
> > to produce.
> >
> > > How would the GRDDL transformation developer support
> > > this?
> >
> > "Transformations may use other, unspecified, mechanisms. For example,
> > see test #atomttl1, in which the the media-type attribute
> > of the
> > xsl:output element bears a "text/rdf+n3" value to indicate a
> > media type other than "application/rdf+xml"."
> >  -- http://www.w3.org/2004/01/rdxh/spec#rule_txprop
> >
> >
> > > How would the GRDDL-aware agent specify its preferences?
> >
> > We didn't design a mechanism for that. The GRDDL spec (and
> > primer) encourage transformations to output RDF/XML, which
> > you can look at as an implicit preference by all
> > GRDDL-aware agents. We considered designing a mechanism to
> > negotiate output formats, but didn't find one that seemed
> > cost-effective.
> I guess since the GRDDL-aware agent is doing the GRDDL
> processing anyway, and it can simply filter the results
> to coerce them from RDF/XML into its preferred format,
> it seems best to leave that task up to the agent, so
> the WG's decision sounds good in this regard.   
> However, I do not see where the spec clarifies whether
> transformation results MUST, SHOULD or MAY be obtainable in
> RDF/XML (though the spec *does* say that formats other
> than RDF/XML *may* be provided):
> http://www.w3.org/2004/01/rdxh/spec#txforms
> [[
> The rule above covers the case of a transformation property
> that relates an XPath document node to an RDF graph
> via an RDF/XML document. Transformations may use other,
> unspecified, mechanisms. For example, see test #atomttl1,
> in which the the media-type attribute of the xsl:output
> element bears a "text/rdf+n3" value to indicate a media
> type other than "application/rdf+xml". GRDDL agents that
> can process such a media type can then produce an RDF graph
> in accordance with the media type. Non-XSLT transforms may
> indicate the RDF graph in some other, unspecified, fashion.
> ]]
> I.e., Would non-RDF/XML formats be *in addition to* 
> RDF/XML, which MUST/SHOULD be provided?

Not in that case; in the atomttl1 test case, the
transformation provides only turtle, not RDF/XML.

That test comes from a real-world scenario where I tried
to convince some Atom/OWL developers to provide a transformation
to RDF/XML, but they were only willing to do turtle.

We specify how the XSLT1+RDF/XML case works completely;
we give an example of how you may use XSLT to produce
another media type (turtle). We discussed using something
other than a MIME body altogether; e.g. javascript API calls.
The spec allows for that without specifying how it works in any detail.

That's our understanding of the state-of-the-art:
  - turtle support is fairly widespread
  - while there are javascript RDF APIs, they're not very mature.

[more on other comments/issues separately...]

Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Monday, 30 April 2007 14:50:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:02 UTC