Re: Updated editor's draft

Shane, Mark, everybody,

Here are my comments on the editors' draft. As usual, I may have
misunderstood some things, but, well, that is why we do these reviews...:-)

Shane McCarron wrote:
> 
> With Ralph's help, I was able to publish an updated editor's draft of
> rdfa-syntax.  If you are going to provide any comments on the document,
> please do it against http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080103/
> 
> I look forward to your input!
> 

(Many of these comments are really small details...) I did not have the
time to review chapter 6 in the sense of cross checking all the examples
with the terms used in the processing rules... Sorry about that.

----

Abstract, 4. paragraph, you refer to "RDF Classes and Properties" (in
paranthesis). At the minimum I think it should say "RDFS Classes and
Properties"; I wonder whether "RDF(S) Classes and Predicates" is not
better. (Predicate is the official term term in RDF, as correctly
referred to in the RDF terminology section, too). Having said that, RDFS
refers to properties in, say, subProperty, so there is an inconsistency
there, too... Sigh...:-(

----

In the Status section the link "RDFa Processor Conformance" seems to be
wrong. I also wonder whether the examples given in the text (for
outstanding issues) are right; isn't @instanceof now solved?

----

2.1, RDFa attributes: the term 'URI' in @href should also be a link
(just like for @src)

----

3.6 N Triples: I guess we should be consistent in putting a space (or
not) before the closing '.' in each triple.

----

3.9 A description of RDFa in RDF terms: it says "The aim of RDFa is to
allow a single [RDF graph]s to be carried in XML". If we talk about a
single graph, is the "[RDF graph]s" correct?

----

4.1 Document Conformance: the example after the list should also include
the @profile, per #5...

----

4.3. RDFa Processor Conformance

I know we have discussed this before, but the statement on "but these
triples MUST be made available in one or more additional RDF [graph]s,
and not in the default [graph]." make me a little bit uneasy as an
implementer. Essentially: I have no idea what this means, simply because
named graphs are not a standardized feature of RDF. I am not sure what
to replace this with, but, well, I wonder...:-(

(If we have a clear idea what this means, maybe and example would be
good, for example)

----

5.4 Comment on the evaluation context, changing the order of processing
(ie, as if <body> were a child of <head>). I know this has been briefly
raised by Mark in one of his mails, but I think both Shane and myself
raised our voice against this and Mark withdrew his proposal on the
matter...

----

5.4, Processing step number 2, setting [new subject]. Several comments here:

   - maybe it should be made clear that all bulleted items are 'else
if'-s! Just to avoid misunderstandings (or making it clear in the
introductory text)
   - my understanding for the usage of @src in <img> was such that @src
should have a higher priority than @instancof, right after @about.
   - (this is being picky, I know but...) for the rule on @instanceof
may be it is worth emphasizing that it is a _new_ bnode
   - per current discussion, usage of @resource and @href should be
considered as pending (ie, this should be decided before publishing...)

----

5.4, Processing step number 4: is that correct?

First of all, it should say [parent object] and not [parent subject].
But, more importantly, I do not see any steps that _sets_ these values.
My understanding is that

   if [current object resource] is set then [parent object] = [current
object resource]
   else if [new subject] is set then [parent object] = [current object
resource]
   otherwise [parent subject] is unchanged

   if [current object resource]  is set and is a BNode then [parent
bnode] = [current object resource]
   otherwise [parent bnode] is unchanged

Think of the case:

  <div about="#A" rel="a:b">
     <div>
     <div rel="p:q">
                 <div about="#k"/>
            </div>
     </div>
  </div>

This should yield to

  <#A> a:b _:x.
  _:x p:q <#k>.

but this means that the intermediate <div> should let the values flow
through, as if it was not around at all... The current rule would
eliminate the bnode generated in the top <div>. Do I miss something?

Actually... I just wonder whether we need two different objects here.
The fact that the [parent object] is a bnode or not is immaterial to the
node itself, isn't it? The only point is that, in some cases, the object
forwarded from the parent is to be used to complete triples. Is there a
different treatment on whether that is a bnode or not?

----

5.4, Processing step, well, general point...

I tried to follow through the following edge case:

<div about="#A" rel="a:b">
   <span rel="q:r"/>
</div>

My current (may be false!) understanding until now was that no triple
should be generated, because the internal 'incomplete triples' (on
<span>) never get completed. However, following the current steps, the
triple

<#A> a:b [].

_will_ be generated. Indeed, step 2.3 will set the [new subject] (by
virtue of the presence of "q:r" in <span>), and step 3 says that the
'incomplete triples' _are_ generated in such a case, no matter what.

My current implementation adds an extra complication to solve that.
First of all, each recursion step returns a boolean signalling whether
incomplete triples have been completed or not. Also: the processing does
complete the incomplete triples if one of @instanceof, @about, @src, or
@property is present. Otherwise, it does it only if at least one of the
recursion steps yields a True value. In the example above <span> does
not get anything from its (non-existing) children, hence it does _not_
complete the incomplete triples.

I am not saying that is the best way of doing it, I am just saying that
this is one way of doing it _if_ we want to avoid those triples...
Alternatively, and to simplify the specification, we may decide to leave
it as is, but be clear that we have that consequence (as far as I am
concerned, we can go either way, a simpler spec is certainly of value!)

----

5.4, Processing step number 5: I thought that @src does not take part in
the determination of current object any more!

----

Comment at the end of 6.1.1.2 says: "A bnode is simply a unique
identifier that is only available to the processor, not to any external
software.". I think that this statement is not fully precise in terms of
the RDF semantics (bnode is an existential thingy). I would say that we
should NOT go into the definition of BNodes in this document, but defer
to the RDF documents, ie, that comment should simply be removed.

----

6.3.1.3. there seems to be some unicode problem in the document in the
6th example: I see "1879 – April 18"

----

7. CURIE Syntax (see also my comment on 6.1.1.1): the text says "a
mapping to use with the '_' prefix, which is used to generate unique
identifiers (for example, _:p)." This should say, in my view, a "mapping
to use with the '_' prefix, which is used to generate unique bnodes (for
example, _:p)."

I thought that the no prefix situation has been clarified, so the
editor's note should be exchanged against the description. My
understanding is that

- ':bla' is considered to be <http://www.w3.org/1999/xhtml/vocab#bla>
- 'bla' is ignored.

Per discussion with Mark it also seems that the intention for

- 'bla:'

is to be expanded into the corresponding URI from the xmlns declaration.
Maybe my reading is incorrect, but the grammar

curie :=   [ [ prefix ] ':' ] reference

seems to indicate that 'reference' is NOT optional, ie, that 'bla:' is,
in fact, incorrect. Do I miss something here? (As far as I am concerned,
I do agree with Mark's interpretation for 'bla:', I am just not sure
that the grammar is correct).

However, I still maintain that the exact interpretation of "_:" is
somewhat pending and should be decided by the group. Reminder: Mark
claims that is should be _one_ BNode (ie, all occurrences of "_:" should
refer to the same BNode per document) whereas my claim is that we have
the liberty to define this in terms of BNode as we wish by virtue of the
semantic mapping of general CURIE-s to the RDFa case, and that it would
make sense to have a _different_ BNode for each occurrence of "_:".
Either way is, in fact, o.k., not a huge deal, but should be documented...

----

Section 9.2.5 and 9.2.6.

I wonder whether these are not leftovers of earlier versions. If my
memory is correct, then usage of the form @property="title" will NOT
yield a triple, only @property=":title" will. If this is correct, I
think most of these paragraphs should be simply removed, the references
to the predefined property and link values of XHTML is irrelevant for RDFa.




-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Friday, 4 January 2008 11:12:23 UTC