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

On Sep 8, 2010, at 12:44 , Manu Sporny 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.
> 

I am sorry but these things have already been discussed, and the WG has decided to go along the lines it has now. I do not see any new information here, ie, no argument that has not been discussed before. Reopening a closed issue is really not a good way forward.

There is _one_ new issue below that I consider more as a bug than a new information. That is not a reason to reopen a closed issue.

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

Correct, the Core document should not necessarily refer to XHTML+RDFa but to RDFa Core. Any RDFa Core parser should suffice. We can certainly make it clear in the spec that a profile document should not make use of any XHTML specific issues in the definition of the 'profile graph'. This is not a fundamentally new issue.

For the rest, while I agree with what Manu wrote in his response, I would also refer to the earlier discussion. 

Ivan


> #1) We have a software architecture where the foundations depend on the
>    finished product.
> #2) It's not good RDF...it's a pattern that no-one else uses.
> #3) To implement it properly you need to be able to query the triple
>    store.
> #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.
> 
> #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).
> 
> #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.
> 
> #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.
> 
> #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.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: WebID - Universal Login for the Web
> http://blog.digitalbazaar.com/2010/08/07/webid/2/
> 


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