W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > October 2004

Various comments from implementation

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 28 Oct 2004 20:09:00 +0100
Message-ID: <418143CC.7020403@hplb.hpl.hp.com>
To: public-rdf-in-xhtml-tf <public-rdf-in-xhtml-tf@w3.org>

Hard to fully distinguish editorial from substantive, because it is 
occasional unclear what is correct behaviour, so the editors may respond 
to the comments by making it clear in a way that differs from my 

1) link and meta special?

In para 3.1
  However, RDF/A provides another mechanism, which is that if a link or 
meta element is used, and no [subject] is present, then the [triple] 
concerns the parent of the element.


  This syntax only applies to the elements link and meta,

however section 4, para 4.2.4
does not restrict this feature to link and meta elements.

FWIW My implementation follows 4.2.4, but don't see that as an opinion.

2) [editorial] suggested reordering of material

As is clear in my discussion, a crucial insight into implementing is 
that some of the object rules apply to some of the predicate rules, and 
some don't.

I think this can be made clearer by restructuring sections 4 and 5 as 

4.1 Processing
4.2 Subjects
4.3 Resource Objects (was 4.4 without 4.4.1)
4.4 Literal Objects (4.4.1 and 5.1)
4.5 Predicates
4.5.1 Predicates for resource objects
4.5.2 Predicates for property objects

3) all-matches principle rather than procedural reading
In section 3 there is a clear declarative all and any matches intent:

See discussion concerning:
     rel="dc:creator" rev="foaf:homepage" 
     property="dc:title" content="Internet Applications"

However, the rules concerning the subject partially suggests a 
procedural processing of try one, if no luck, try the next etc.
The specific text is in para 4.2.3
  If an [RDF/A element] does not contain an about attribute, but does 
contain an attribute of type xml:id  then this is used for the subject.
I think this should be:
"does not contain an about or a nodeID attribute"
and that the previous subsection 4.2.2 on nodeID should clarify that it 
applies in addition to 4.2.1 on about so that

     rel="dc:creator" rev="foaf:homepage" 
     property="dc:title" content="Internet Applications"
would generate six triples (I think)

4) paras  4.3.4 versus para 4.4.3
Para 4.3.4 and para 4.4.3 overlap but with differnet processing:


  <p nodeID="foo" rel="eg:prop">
       <link nodeID="bar" href="http://example.org"/>

By 4.4.3 we get
_:foo eg:prop _:bar .

By 4.3.4 we get
_:bar eg:prop <http://example.org> .

That doesn't seem right.
I suggest deleting 4.3.4 and and replacing with simplified 
version of using hasReferenceTo as default predicate if none 

This would give

_:foo eg:prop _:bar .
_:bar xhtml2:hasReferenceTo <http://example.org> .

5) para 4.4.3 and children with no explicit subject

I think para 4.4.3 should be clear that it applies to all child elements 
of an element with a @rel or @rev attribute with no @href.
If the child element has a @nodeID or @about attribute (or both) then 
they are used to give the *object* of the triple for the parent element.
If the child element has neither a @nodeID or @about attribute but an 
xml:id attribute then the xml:id attribute is used.
If the child has none of @about @nodeID or @xml:id then a gensym 
(corresponding to the child) is used (this behaviour is not in RDF/A at 
the moment, hmmm but I have implemented it).

It allows
   <link about="#foo" rel="eg:prop1">
        <meta property="dc:creator" content="Jeremy Carroll"/>

to generate two triples
<#foo> eg:prop1 _:a .
_:a dc:creator "Jeremy Carroll" .

Received on Thursday, 28 October 2004 19:09:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:18 UTC