[HTML] comments on RDF/A primer

Some brief comments on the RDF/A Primer 1.0 editor's draft [1] ...

On the whole [1] looks good, and I support publication of this document as a Working Draft.  I have no problems with the design of the RDF/A syntax. I do, however, have some comments wrt the particular examples given in [1].

Minor stylistic comment: I suggest the code examples containing HTML and the code examples containing triples be given in different colours, or some other way of telling them easily apart at a glance.

 -- Comment 1. Use of dc:creator --

One of the triples embedded in the example in section [3.1 Literal Properties] is:

<> dc:creator "Mark Birbeck"^^XMLLiteral .

One of the triples embedded in the example in section [3.2 URI Properties] is:

<> dc:creator </user/markb> .

... where the resource </user/markb> is 'user-profile page for [Mark Birkbeck], a page that summarizes all of his albums and user profile information for others to see.'

Although these usages of the dc:creator property are not inconsistent with much current practice, I do not believe either usage is consistent with the current definition of dc:creator [2], which is: 'An entity primarily responsible for making the content of the resource.' It does not make sense for either an XML Literal, or another web page, to be the 'entity primarily responsible for making' the web page.

I strongly suggest that the Task Force consult the DCMI Usage Board (chaired by Tom Baker) before subsequent Working Draft publications of this document, especially with respect to the use of the dc:creator property. Although current real-world usage of DCMI metadata terms is highly inconsistent and ambiguous, the DCMI Usage Board is making great pains to improve this situation, and related specifications such as the RDF/A primer could provide significant support to this effort by ensuring that they are consistent with current DCMI recommendations.

Furthermore, the example from section [3.2 URI Properties] does not help to avoid practices that lead to URI collision, because it implicitly suggests the use of the URI of a web page as an identifier for the person described by the web page. 

A better set of triples would be:

<> <foaf:maker> _:aaa.
_:aaa a foaf:Person.
_:aaa foaf:homepage </user/markb>.

However, this is obviously more complex and doesn't exemplify the feature at hand. Therefore I suggest the TF modify the example to use a property other than dc:creator, where there is no implied ambiguity between some abstract thing and a web page about that thing. (Try thinking of all the possible relationships between documents - cites, replaces, is version of ...) 

 -- Comment 2. Use of shutr:takenWith --

The examples in this section again encourage practices that lead to URI collision.

The example in the section [4.3 Qualifying Chunks of Documents] generates the following triple:

</user/markb/photo/23456> shutr:takenWith </user/markb/cameras#nikon_d200>

Firstly, this is missing a full stop.

Secondly, the URI </user/markb/cameras#nikon_d200> denotes an element in an XHTML document.

>From [3]: 'The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource.'

>From [4]: 

  'For documents labeled as 'text/html', [RFC2854] specified that the
   fragment identifier designates the correspondingly named element,
   these were identified by either a unique id attribute or a name
   attribute for some elements. For documents described with the
   application/xhtml+xml media type, fragment identifiers share the same
   syntax and semantics with other XML documents, see [XMLMIME], section
   5.

   At the time of writing, [XMLMIME] does not define syntax and
   semantics of fragment identifiers, but refers to "XML Pointer
   Language (XPointer)" for a future XML fragment identification
   mechanism. The current specification for XPointer is available at
   http://www.w3.org/TR/xptr. Until [XMLMIME] gets updated, fragment
   identifiers for XHTML documents designate the element with the
   corresponding ID attribute value (see [XML] section 3.3.1); any XHTML
   element with the "id" attribute.'

I.e. if http://shutr.net/user/markb/cameras returns a representation with content type 'application/xhtml+xml' then <http://shutr.net/user/markb/cameras#nikon_d200> necessarily denotes an element in an XML document, which means that the triple:

</user/markb/photo/23456> shutr:takenWith </user/markb/cameras#nikon_d200>.

... says something like 'this photo was taken with this XML element.' 

This probably isn't what you intended for the semantics of the shutr:takenWith property. Even if it was, this example implicitly encourages the use of a URI to denote both some abstract or physical thing [a camera] and a part of a document that describes the thing, leading to URI collision.

To exemplify this feature of RDF/A I suggest you make statements about things that are clearly sections or parts of a document, which is more consistent with the semantics of fragment identifiers as given by RFC 3236 [4].  You could still use dc:title and dc:date do give titles and modification/creation dates for these sections. You might also consider using the dcterms:modified and dcterms:created properties, instead of dc:date.

I know these features of web architecture seem complex and perhaps even fragile, but by adhering as strictly as possible to them at this stage you would be following the safest, least ambiguous course of action. 

That's all, 

Al.

[1] http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-15-rdfa-primer
[2] http://dublincore.org/documents/2005/06/13/dcmi-terms/#creator
[3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
[4] http://www.ietf.org/rfc/rfc3236.txt

---
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440

Received on Monday, 23 January 2006 20:21:47 UTC