Re: comments on RDFa Syntax

Hi Ben,

Great comments, too. Many thanks.

I think most of them will not be controversial, so I'll focus only on
a couple of things.

> At a high level, I think this document is now *very* useful for
> implementors. I'm a bit worried that Sections 4 and 5 have enough
> overlap that we could miss some inconsistencies. Let's be very careful
> in the reviews.

The intention is that each 'blue box' is explained in more detail with
its own section. We don't quite have a one to one on that yet, but
that's what we'd like to do, and I hope that would make it easier to
check.

So I guess what I'm saying is that the overlap is intentional, and so
you are definitely right that the two sections need to be kept in
sync. But hopefully by making the relationship between a summary and
its detail 'one-to-one' we can keep things consistent.

Just in passing, the rationale is that the reader can look at the
processing overview, and you get a set of high-level steps, which are
essentially 'generic RDFa'. The 'blue boxes' tell you the implications
of this 'generic' step in the context of XHTML. And then the following
section gives you a detailed discussion with examples of the
'blue-box' summary.


> [snip]


> - "whether more triples might be generated during processing than are
> outlined here". What do you mean here? Where might other triples come
> from? I'm confused by the purpose of this statement.

This is essentially that an RDFa+XHTML parser might generate more
triples than are here, and were it to do so, that would not stop it
from being 'conformant'. However, we have to stress that it must
generate at least the triples implied. So if, for example, a parser
receives this input:

  <img rel="foaf:depiction" src="o" />

To be conformant it *must* generate a triple with a predicate of
foaf:depiction and an object of <o>. However, if a parser also
generated a triple that said the rdf:type of <o> was foaf:Image, then
that would *not* make it non-conformant.

I think this is quite an important point, because (a) it allows for
the RDFa -> action mapping technology to be used for lots of things,
and (b) it allows people to experiment with new parsing rules that we
might add in future versions of RDFa+XHTML.

> [snip]

> Rule #4: if there is a @rel, @rev, or @instanceof on the element,
> chaining occurs: set [current resource] to [current object resource].
>
> Rule #5: same as now, except use [current resource] as subject instead
> of [current object resource].

Obviously we need to discuss this, but a general point is that I think
we should define our rules in 'generic' terms. That's why I've tried
to say things like 'if a triple is generated', etc., rather than 'if
this or that attribute is present'. I'm hoping that this will make it
easier to produce implementations, and make it easier to discuss them,
too.


> - I'm not sure what to think about not recursing down XML Literals... Is
> that really what we want? What's the argument here?
>
> IMO, if the RDFa in the XML literal is not self-contained, then it's
> going to be a *very* weird XML Literal to throw around. If it *is*
> self-contained, e.g. with an enclosing @about and all required
> namespaces, then why not parse the RDFa?

I hadn't thought of the whole issue at all until I was
reverse-engineering Ivan's parser. :) But it's not unlike having a
script tag in a string, in JavaScript, or a comment in your C++--the
rdf:XMLLiteral is effectively 'escaping' the mark-up, and so it can no
longer be seen as a collection of triples, and is just a 'string' (so
to speak).

If you put RDF/XML into an XML literal in an RDF/XML document, that
too, would not be parsed for RDF.


> [snip]

> 5.2.2.2:
> - "for example when a picture is taken by Mark, but that picture also
> depicts him:"
>
> that's not what the markup says. The markup says:
>
>   rel="dc:creator" rev="foaf:img"
>
> and the triples match.
>
> change the markup and triples, or the text.

Do you mean because I've used the word 'depicts'? I'm using it in the
English sense....that doesn't mean I have to use foaf:depiction, but I
can if the feeling is that this will confuse. :) (Or do you mean
something else altogether, that I've missed?)


> 6. CURIEs
>
> For now, take out the reference to the external document. You're just
> asking for trouble :) Calling them "CURIEs" is a good enough reference.
> If I'd written it, I would have just talked about "Compact URIs", but it
> seems the furor around the word "CURIEs" has waned, so okay, let's keep
> the terminology.

LoL.

But what if the reason the furor has subsided is actually because we
stuck to our guns over the last couple of years, and consistently
defended a 'correct' solution? It is certainly increasingly common for
specifications to not use QNames, and instead to define a 'compact
URI'-style production, so in that context, no-one is going to say to
us that we have to use QNames instead.

So you are left asking what exactly it is that people will be objecting to?

I'd be interested to hear Shane and Steven's views on this, and I'm
happy to defer to whatever they think is appropriate here. (Which
doesn't rule out that we might need to vote on it.)

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 Friday, 14 September 2007 11:56:11 UTC