Re: Updated editor's draft

Hi Ivan,

Thanks for your comments--much appreciated.

> 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...:-(

Yes, I see what you mean. :) Since this doesn't affect the content,
I've actually replaced the whole thing with this:

  ...RDFa specifies only a syntax and relies on independent specification
  of terms (often called vocabularies or taxonomies) by others.

Is that ok?


> 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?

Thanks. Removed the reference to @instanceof.


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

Eagle eyes! Done.


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

Done. I prefer the extra space myself, if that's ok with everyone.
However, if there is some kind of 'house-style' for this, then let me
know.


> 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?

Right...now singular.


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

Done.


> 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)

Fair point. All we're concerned to say is (a) that no extra triples
should be present in the default graph, but (b) additional triples MAY
be made available in some other way, so I've flipped the logic around:

  A conforming RDFa Processor MAY make available additional triples that
  have been generated using rules not described here, but these triples MUST
  not be made available in the default [graph].

Is that ok? In addition, I've added a paranthetical note to give
implementers a little clue as to how they might go about this, but
this is outside of the 'MUST':

  (Whether these additional triples are made available in one or more additional
  RDF [graph]s is implementation-specific, and therefore not defined here.)


> 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...

Yes, I thought Shane was going to kill that. Done now.


> 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)

Good point. I've done both, by indicating that 'first match' only is
applied, and also by adding the word 'otherwise' to the beginning of
each rule.


>    - my understanding for the usage of @src in <img> was such that @src
> should have a higher priority than @instancof, right after @about.

Yes, you are right. I have verified slightly different rules in my
implementation than those in the document, which I will work in now.
Essentially, we need to distinguish between the situation where @src
has a @rel, and one where it doesn't.


>    - (this is being picky, I know but...) for the rule on @instanceof
> may be it is worth emphasizing that it is a _new_ bnode

Not picky at all. :) It all all helps to make things clearer, and
that's now done.


>    - per current discussion, usage of @resource and @href should be
> considered as pending (ie, this should be decided before publishing...)

Right. Added an 'issue' block.


> 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.

Yes, you are right. I didn't get this part finished because I was
still verifying that my implementation generated the correct triples.
I'll work this in now.


> 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?

That's exactly the problem I was fixing in my implementation before
Xmas, but I ran out of time to incorporate it into the rules in the
document. The basic change I made was actually quite simple, and seems
to be that we should clear the two values only when a [new subject] is
set.


> 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?

I think you are right, but I haven't had time to verify this 100%. My
previous thinking was that we need to know how we obtained the object
that is about to be used as a subject, so that we can know whether it
can be overridden or not. If that's the case, then whether we use a
flag and one object or have two objects and no flag, makes little
difference.

However, it's looking increasingly like we don't have to make the
distinction; I have a few more tests to run, before I'm certain
(although the fact that you also seem to be thinking that the
distinction is unnecessary makes it likely that it's right).


> 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.

That's a very good edge-case. I'll look into this some more.


> 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!)

I think your proposal sounds good, and probably wouldn't
overcomplicate things. I'll look at this once I've got some of the
other things sorted out. For now I'll add an 'issue' box.


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

Mmm...but why? I don't recall any discussion that said we should no
longer support this:

  <img about="#ivan" rel="foaf:img" src="ivan.jpg" />

And if we do support it, then all the usual rules should apply.


> 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.

Ok. The only point of having _something_ here is to make it clear to
implementers that they need to be careful. I've not changed anything
here, as yet.


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

Thanks. I've just changed it to:

  "(b. March 14, 1879, d. April 18, 1955)"


> 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)."

Ok. I've added text that says it must conform to RDF bnodes, and I'll
add a reference to the right place later.


> 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>

Right...corrected.


> - 'bla' is ignored.

Done, by saying that triples must not go into the default graph.


> 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).

I thought I'd replied to this, but since I have a habit of writing
replies and not pressing 'send', this one may not have gone off. :)
Anyway, I think the grammar is correct; essentially, 'reference' is
not optional, but since a relative URI can be empty, you end up with
the same effect as you are describing.


> 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...

My argument was that we don't really have the freedom to define this
as we like. (Did I really not reply to this already?) We need bnodes
to exist at the level of CURIEs, and not just at the RDFa level, since
the whole point of CURIEs is that they will work in other situations
(such as SPARQL, for example).

However, I agree that this is a useful feature, and will come back to
this when I've done everything else.


> 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.

I think you are right, and what seems to have happened here is a
simple cut-and-paste from the XHTML 2 spec, which is out of sync. I'll
have a chat with Shane before I go hacking into it, though.

Thanks again for your very useful comments!

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Sunday, 6 January 2008 17:29:30 UTC