Re: customer feedback, please

Dan Connolly wrote:

>   RDF/XHTML, for XHTML 2
>   http://www.w3.org/MarkUp/2004/02/xhtml-rdf.html
>
>   GRDDL, a profile for XHTML (all dialects)
>   http://www.w3.org/2003/g/data-view
>
> The proposals are complementary; you might find either
> or both suit your needs...
>
> You're welcome to comment in any way that suits you; here
> are some suggested comments; please check all that apply:

Hi all,

This is a review of the two specifications above, carried out with some of
my colleagues on AKT (principally Steve Harris <swh@ecs.soton.ac.uk>).

RDF/XHTML
=========

[X] we tried RDF/XHTML
[X] we need better rationale/motivation for RDF/XHTML
[X] we need better documentation for RDF/XHTML

First, some context. We have a use case for embedding RDF in XHTML in which
we generate XHTML pages from an RDF repository, and wish to associate the
XHTML with the RDF that we used. At present, we link to the generating RDF,
rather than embed it, but we have experimented with embedding the RDF/XML
in CDATA sections in the past.

Our views on RDF/XHTML are extremely mixed. There are some aspects which we
feel make a valuable contribution to the linkage between the XHTML and RDF
worlds, but too much of it feels like reinventing the wheel (or rather,
another syntax for RDF). While we recognise that it is attempting to
address the issue of embedding RDF in XHTML, we do not feel that it
presents an appropriate method by which that might be accomplished in its
current form.

Pro:

- Section 4.2 Identifying Resources
  This addresses a specific need that we have in the open hypermedia (and
  conceptual open hypermedia) community, that of associating a text span
  with an RDF resource or instance in an ontology (in the sense that the
  content of that text span refers to the instance).

  We're slightly unsure about the use of QNames to refer to RDF resources,
  as we further explain below.

Con:

- Insufficient motivation has been given for the need to embed RDF within
  XHTML, rather than link to it via the link element. Elsewhere in XHTML,
  non-XHTML resources such as images are included in a document by linking,
  or in (rare) cases, by using the data: URI scheme. Why have these
  approaches been judged insufficient or inappropriate in this case?

- Insufficient motivation has been given for the need to invent yet another
  syntax for RDF.

  - RDF/XHTML is less expressive than RDF/XML, particularly with respect to
    bNodes and the lack of nodeID.

  - The meta/link distinction for literal/resource valued properties in
    Section 3.4 is awkward, since meta can be used to represent some
    resource valued properties. For example, the dc:creator property in the
    following has an anonymous resource as its value:

    <meta property="dc:creator">
      <meta property="con:fullName">John Doe</meta>
    </meta>

    Can the about property be used to specify a named resource as a
    property value, as in the following?

    <meta property="dc:creator">
      <meta about="#johndoe" property="con:fullName">John Doe</meta>
    </meta>

    Finally, can a meta element which only has an about attribute be used
    to specify a named resource as a property value, as in the following?
    (compare with the use of such a meta element to specify a triple
    subject in Section 3.3)

    <meta property="dc:creator">
      <meta about="#johndoe"/>
    </meta>

    If this is the case, is the link element still needed to express RDF in
    XHTML?

  - More needs to be said about the interaction of RDF/XHTML with the
    existing uses of the meta and link elements.

- The about attribute uses both QNames and URIrefs ("p:TonyBlair" vs.
  "#q1"); we have a strong preference for the latter, which does not
  require us to declare a namespace for external resources.

  Furthermore, the XML Namespaces spec (http://www.w3.org/TR/xml-names11)
  makes no mention of the use of namespaces and QNames in attribute values.
  Is this use of QNames in attribute values (as seen in RDF/XHTML)
  acceptable? If so, where is this usage defined? How does one avoid
  clashes between namespace prefixes and URI schemes?

- The use of the about attribute (in Section 3.4 and elsewhere) and its
  relationship to the nesting of the meta element is insufficiently
  explained, and is confusing in its present state.

  For example, would the following fragment produce the triples below?

  <meta property="dc:creator">
    <meta about="#foo" property="con:fullName">Fred Foo</meta>
    <meta about="#bar" property="con:fullName">Bill Bar</meta>
  </meta>

  <> dc:creator <#foo>.
  <> dc:creator <#bar>.
  <#foo> con:fullName "Fred Foo".
  <#bar> con:fullName "Bill Bar".

  If so, what triples would the following fragment produce, bearing in mind
  the nested meta example in Section 4?

  <meta property="dc:creator">
    <meta property="con:fullName">Fred Foo</meta>
    <meta property="con:fullName">Bill Bar</meta>
    <meta about="#baz" property="con:fullName">Barry Baz</meta>
  </meta>

- The use of <span resource="..."> to indicate that a text span refers to
  some resource is a positive step, as we note above. However, the spec
  states that the triple generated by this tag has the document as its
  subject, rather than the content of the element (the context of the
  reference). We feel that both are valuable, in the same way that the
  Annotea schema includes links to both an annotated document and to the
  specific context for that annotation. Consequently, we believe that two
  triples should be generated, one to the document, and one to the context
  (using Xptr or a named anchor).

GRDDL
=====

[X] we tried GRDDL
[X] we tried one or more of the GRDDL demo services
	http://www.w3.org/2003/11/rdf-in-xhtml-demo
	http://www.w3.org/2004/01/rdxh/grddl-xml-demo
[X] We intend to publish a GRDDL transformation for our dialect
	(e.g. ideally, Dublin Core folks might take on publication and
	maintenance of
	http://www.w3.org/2000/06/dc-extract/dc-extract.xsl
	or Creative Commons might take on maintenance of
	http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokCC.xsl)
[X] We don't think the generalization to XML is worthwhile;
	please take out section "3. The GRDDL attribute in XML"
[X] We need the "XML Namespaces and embedded RDF" section
	finished and tested
[X] We need better documentation for GRDDL of the form ____

In summary, we like GRDDL. It's a neat method of providing an RDF
translation of XHTML documents that does not impose excessive global
restrictions on the form of the XHTML used, and there's good motivation
given in the linked design history. This draft needs to be fleshed out
further, and we'd like to see that happen.

Our specific niggles are few, and are as follows:

- The format of the values taken by the profile attribute on the XHTML head
  element is underspecified. How will GRDDL interact with existing uses of
  this attribute? Should there be a call for clarification on this
  attribute in XHTML2? (we note Karl Dubost's message on this subject at
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2004Jan/0005.html)

- There's no way of indicating which ontologies/schemas will be used in the
  RDF generated by a given transformation, so there's no way for an agent
  to determine which tranformation is the 'right' one except by performing
  them all and inspecting the results.

- Following from the previous point, Section 4 seems incomplete (as a way
  of describing the capabilities of interpreters), because it only
  describes the characteristics of the source (untransformed) document, and
  not the target (transformed) document.

Overall
=======

[X] Two proposals is one too many. The existince
   of GRDDL makes RDF/XHTML insufficiently endorsed.

-- 
Nick Gibbins                                            nmg@ecs.soton.ac.uk
IAM (Intelligence, Agents, Multimedia)             tel: +44 (0) 23 80598347
Electronics and Computer Science                   fax: +44 (0) 23 80592865
University of Southampton

Received on Tuesday, 30 March 2004 10:50:46 UTC