Re: Comments on PR-rdfa-syntax-20080904

Hi Danny,

> Although you said your response wasn't formal, Toby's response that
> he's been able to work with the spec as it stands shifts my position
> significantly. (I'll argue "there exists a well-informed developer"
> vs. "for all PHP scripters" over a beer sometime :-)

I look forward to that. :)

So thanks to Toby for his comments, and to you for considering them.


> Hence I formally withdraw all my criticisms, bar two^H^H^H one:
>
>>>> * 4.3. RDFa Processor Conformance *
>>>>
>>>> "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]. (Whether these additional triples are
>>>> made available in one or more additional [RDF graph]s is
>>>> implementation-specific, and therefore not defined here.)"
>
> I strongly recommend rewording this to something like:
>
>>>> "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 [RDFa-derived graph]. (Whether these additional triples are
>>>> made available in the same or additional [RDF graph]s is not defined here.)"
>
> Maybe not the perfect wording, but for a set of html2rdf document
> processors to only get the RDFa interpretation is *broken*.
>
> Say I have a document that only has GRDDL-accessible triples, and an
> RDFa processor gets there first, the result would be one empty
> "default graph", plus some auxiliary implementation-specific triples,
> without any unambiguous connection to the document from which they
> were derived. My interpretation of the RDF-in-HTML efforts is to
> maximise the explicit data available from the document, not leave it
> to the consumer's fortune.

What you are saying makes a lot of sense. And the irony of us arguing
about this is that I proposed the 'default graph' solution precisely
to enable the kind of flexibility you desire -- i.e., as a way of
enabling people to innovate without being told that they were
'non-conformant'.

At the time of the discussion on this issue there was a lot of
pressure -- understandably -- to ensure that an RDFa parser generated
'one-and-only-one' graph. My proposal that this should be called the
'default graph' and that other graphs are allowed, was an attempt to
retain that precision, at the same time as leaving open the way for
people to experiment.


SPARQL

I based the idea on the way that SPARQL defaults to querying the
default graph, but allows you to run queries against named graphs. In
other words, although I didn't define how an implementation could
manage these multiple graphs, I felt confident it could be done
because SPARQL already had the features necessary.

Perhaps a more concrete example than I have given so far, will clarify things.


MICROFORMATS

In a separate thread, Martin is (quite understandably) suggesting that
the following would be a good way to bring Microformats users 'into
the fold':

  <div class="vevent">
    <h3 class="summary">Have I Got Old News For You</h3>
    <p class="location">BBC2</p>
    <p>
      <span property="dtstart" content="2008-06-28T21:00:00">Saturday 28 June,
      9</span>-<span property="dtend"
content="2008-06-28T21:30:00">9.30pm</span>
    </p>
    <p class="description">Team captains Paul Merton and Ian Hislop
      are joined by returning guest host Jeremy Clarkson and
      panellists Danny Baker and Germaine Greer for the
      topical news quiz. <abbr title="in stereo">[S]</abbr>
    </p>
  </div>

Note the mixing of RDFa properties with the Microformats structure.

In short, he is proposing that Microformats can be improved by
'co-opting' the RDFa attributes in exactly the same way that it has
done for @abbr, @title, and so on.

Now, we have had a lot of discussion about how to refine RDFa to make
it easier for authors by providing mechanisms for defaulting
namespaces. But since we couldn't agree on that in the first version
of RDFa, we decided to leave it until later.

So we now have a problem where people want to make use of some of
RDFa's features but we're not yet ready.


CONFORMANCE

We certainly don't want to allow parsers to simply add any of these
kinds of processing rules and still call themselves 'conformant';
hence the pressure in the initial debate to say that there should be
'one-and-only-one' graph that is generated from the RDFa rules.

But what if through trying things out and refining the processing,
someone came up with some clever enhancements to RDFa? We certainly
don't want to inhibit that.

And as I said, this was exactly my concern; that I didn't want to
prevent people from experimenting with different features, or
hard-coding various mappings for their organisation, etc., by having a
very rigid notion of conformance.


DEFAULT GRAPH

So, the idea of using a 'default graph' in RDFa was to say that there
is notionally a set of triples that *must* be generated by the parsing
rules, and to achieve conformance you must generate no more and no
less than these triples. And in addition, whilst implementers are free
to add any other triples they like, using whatever rules they like,
they should be aware that it is best to keep those triples notionally
separate, so that if the RDFa rules change in the future, your triples
will be safe.

To put it a different way, if you put any other triples into the
default graph, no-one is going to be knocking on your door -- it's up
to you. :) But if future rules add triples that somehow conflict with
the rules you've invented, that's not going to be an acceptable
argument against the new rules.


@ALT ON IMG

In my RDFa parser, for example, I use the @alt attribute on <img> as
an rdfs:label for the resource identified by @src. It's not in the
RDFa spec, so I don't put the triple in the default graph; but it's
been a useful experiment to see how it might work, and it's easy
enough for my application to get at, because I can run queries across
multiple graphs.

Now, if the core RDFa rules change such that @alt on <img> means
something different to how I have defined it, my application won't
break, because in the default graph I'll get the 'officially
sanctioned' triples, whilst in my 'private' graph I'll still get my
rdfs:label.

And of course, if the 'official' triples also map to rdfs:label, then
I could consider modifying my processor so that I don't bother
generating my own 'private' triples for @alt.

But whatever happens, if a discussion runs on the list about 'how
should we interpret @alt on <img>' I can't expect any sympathy if I
say 'we must interpret that as rdfs;label, because my parser puts that
into the default graph'.


MICROFORMATS AGAIN

To return to Martin's example; an organisation is certainly free to
implement their own RDFa parser that processes the event example
above, and for that parser to arrive at the right answer _for them_.

But at the same time, the authors of the RDFa specification reserve
the right to refine the rules further in the future, to suit the
largest number of people. And it may well be the case that this:

  <span property="dtend" content="2008-06-28T21:30:00">9.30pm</span>

does *not* add the same triples that this fictitious organisation has
decided it should add; perhaps we'll require @profile, or perhaps
we'll say that there is a default namespace for 'dtend'...or perhaps
something else altogether.


I don't want to imply that we haven't thought about what the solution
might be to the 'abbreviated values' issue, because we have. I'm just
trying to illustrate that the key idea is to ensure that the language
can be extended without being 'blocked' by cries of 'but the change
you are proposing for RDFa 1.x means my parser won't work!' (Which is
why I also used the @alt on <img> example.)


> My other substantive objection is (quoting you rather than the spec):
>
> "I don't think it is true that an author needs to understand RDFa."
>
> I have a fundamental disagreement on that statement, but in the
> informative context it appears in the spec I don't think it makes much
> difference - so kindly ignore :-)

Many thanks.


> btw, my use of language like "gives me the impression of seeming
> messy" is that of someone who's effectively overlooking the spec as a
> whole afresh, rather than having being concentrating on the minutiae
> for a long while. And too wimpy to say "that sucks" ;-)

Ah...so you mean that we got off lightly. ;)

Thanks again for taking the time and trouble to review -- it's very
much appreciated.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Monday, 15 September 2008 09:23:30 UTC