Re: Ongoing objection to RDFa Profiles format (as XHTML+RDFa)

Hi Manu,

Thanks for this.

There are a number of points that aren't quite correct, so I'll try to
clarify them.

On Wed, Sep 8, 2010 at 11:44 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> I am going to attempt to summarize an issue that Mark raised over the
> weekend re: RDFa Profile documents. He intends to raise this as a Last
> Call issue - so this is mostly a heads-up that we're going to be
> revisiting this issue before going into LC. I may not capture everything
> that we discussed, so Mark will have to correct/elaborate as necessary.
>
> He has one primary objection:
>
> The RDFa Profile format is expressed in RDF - and that is not good
> design. See the 4 points below for an explanation of why.

That's right. Note however that in your follow-up email you describe
this objection as being about /external/ RDF, and that is not the
issue. The issue is the use of RDF to define data that is out-of-band
for an RDF document, such as prefix mappings, vocabularies, etc.
Logically this means that you need an RDF parser in order to build an
RDF parser.


> The new information that he has provided is:
>
> Per the spec at this moment in time, we're using XHTML+RDFa as the
> normative RDFa Profile document format. This means that an SVG+RDFa
> parser that builds on top of RDFa Core is also going to have to be an
> XHTML+RDFa parser in order to process the RDFa Profile documents.

>From a software architecture standpoint it means that any RDFa parser
needs to 'contain' an XHTML+RDFa parser. I used SVG as an example, but
it would also include such scenarios as an OGP-only parser (i.e., a
parser that only supports the <meta> tag).

In this context you raised the point that an OGP-only parser would be
non-conformant, and whilst that's true, my problem is that structuring
the spec in this way means that you cannot implement anything less
than the full spec, unless you omit profiles.

You also suggested that we could change the spec so that the profile
document is constructed in the same language as the source document,
and perhaps use content negotiation on the server to decide which
profile to deliver.

This would mean (a) that the Googles and Facebooks would not be able
to publish a simple profile that could be used by anyone, in any
document, and (b) server configuration determines the behaviour of
documents, rather than simple document processing.


> #1) We have a software architecture where the foundations depend on the
>    finished product.

By this I mean that there are no layers -- to implement part of the
whole you have to implement the whole.


> #2) It's not good RDF...it's a pattern that no-one else uses.

By this I mean that in no other RDF serialisation do we find
non-triple information (such as prefix mappings) being expressed with
RDF.


> #3) To implement it properly you need to be able to query the triple
>    store.

This doesn't mean that the query mechanism has to be defined, but it
does mean that an implementer must allow triples to be extracted from
the store in order to obtain the mappings, and therefore /some/
retrieval mechanism must be available.


> #4) We now have to maintain a vocabulary. We have all these terms
>    flying around, have to devise a namespace for them, and so on.

Hopefully that's clear.


> #1 means that we require an XHTML+RDFa parser in order to parse
> XHTML+RDFa. Mark is asserting that this is bad design and we should use
> a dead-simple format for the RDFa Profile document (perhaps a key-value
> text file - easily parsed by any language, no heavy RDFa requirement).

That's one proposal...yes.

Anther proposal I had was to still use RDFa documents to carry the
profile, but only use the processing rules that apply to
@prefix/@xmlns/@vocab values. The result would be a list of prefix
mappings which would then be used to supplement the processing from
that point on.

This means that RDF is no longer used, there's no need to design and
maintain a vocabulary, there's no need for a retrieval mechanism, and
the only processing that is required is that for extracting prefix
mappings and setting the default vocabulary.


> #2 means that no other RDF language refers to an external RDF document
> to modify processing rules. Mark asserts that the external document
> SHOULD NOT be RDF.

It's not that no other RDF *serialisation* refers to an external
document, it's that no other RDF serialisation uses RDF to define its
abbreviations. In other words the external part is not relevant;
expressing prefix mappings and vocabularies using RDF is flakey.


> #3 means that the design is more complicated than necessary - requiring
> an RDFa Processor to not only generate triples, but also understand the
> triples that it generates. This is a change from RDFa 1.0, where an RDFa
> Processor only had to generate triples.

Correct.

I should also add that I have never seen a justification for using RDF
to express prefix mappings, although I've enquired.


> #4 means that vocabulary management is a difficult task. Mark asserted
> that he would rather that we not deal with vocabulary management as it
> often time consuming and difficult to get vocabularies right.

Correct.

Once again, thanks for summarising my objections Manu.

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 Wednesday, 8 September 2010 14:10:33 UTC