- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 26 Feb 2010 09:44:51 +0100
- To: Mark Birbeck <mark.birbeck@webBackplane.com>, W3C RDFa WG <public-rdfa-wg@w3.org>
- Message-ID: <4B878A03.9020400@w3.org>
Hi Mark, On ACTION-4... I have read through[1] and I try to compare it with Manu's earlier document[2] on RDFa vocabularies to see where the differences are. I have the impression that the two approaches are almost the same (though I may miss something here). Which is great because I think (I hope:-) we all agree that some sort of a mechanism in this direction (one can just look at the examples in your blog) is absolutely essential... What I see as a general mechanism (with the differences) in both cases is as follows. 1. An RDFa attribute is defined whose values are URI-s for vocabulary management. [1] uses @profile, [2] uses @vocab. If the proposal on '@profile everywhere' gets through in the HTML5 world[3] then @profile might be indeed a better choice, otherwise we may have to stick to an RDFa specific attribute, because @profile will then vanish from HTML5... But I guess this is a detail for now. 2. By dereferencing that URI, one gets to a document that describes a number of keyword->URI mappings (let me call this a 'keyword definition document', a.k.a. KDD:-). From that point on, those keywords can be used anywhere where CURIE-s can be used in the original RDFa document. Document [2] does not specify the syntax of the KDD. Instead, it describes some RDF terms, ie, RDF triples, that specify the keyword->URI mappings and you are supposed to get through dereferencing. My understanding, on the other hand, is that [1] defines the keywords in terms of xmlns statements in the KDD which the user can define in HTML and/or JSON. (3. Note that, as a small additional step that I referred to in [4], I think that extending [2], ie, the RDF triples, to also define namespace prefixes additionally to keywords is a trivial step to do and can be added to [4] easily. That would obviously make the life of authors easier: one could define both keywords and namespaces at will.) First of all, is it correct that the few differences between the two are the one above? If so, I have a question and a comment - Presumably [1] relies on the approach that the namespace declarations in the KDD are 'taken over' to the startup RDFa document as if they were defined there. Ie, to use your example, the fact that xmlns:Person is defined in the KDD means that the original RDFa document inherits those CURIE prefixes. But, as far as I know, the current RDFa spec disallows the usage of CURIE-s without ':', except for the predefined XHTML keywords. In other words, <span xmlns:prefix="blabla" rel="prefix"/> is not kosher in RDFa 1.0, and that should be modified. Would not that create backward compatibility issues? The approach in [2] does not seem to require a modification of the current RDFa, but, instead, an add-on to the current RDFa processing. - I must admit I am uneasy with the introduction of JSON in the picture. From the point of view of non-Javascript implementers Json (though of course manageable from most languages these days) represents a different file syntax that the implementation has to understand for that particular purpose. Even if it _is_ simple, it is an additional mechanism... In other words, I would have to have two different parsers at disposal to do the same job (namely extract the namespace declarations and add them to the ones valid for the node that is just being processed.) I find this as a drag...:-( My personal, favourite approach (and that also addresses the missing syntax issue in [2]) is to restrict the syntax of KDD to RDFa. Implementations already have a mechanism to parse RDFa:-), and that should be enough. Note that, though it is true that defining a vocabulary, mainly in approach [2], is a little bit more complicated in RDFa than in JSon, I do not think that matters too much. 90% of the authors will not define KDD-s, they would just use those that will be defined by CC or Google, or, well, W3C. Ivan P.S. B.t.w., just because that was raised as a plan for next week's meeting, this discussion is very relevant to ISSUE-11. Indeed, if either [1] or [2] (or a mixture thereof) is adopted, then a solution to ISSUE-11 is to define a number of namespaces in a default KDD as provided by W3C or the spec or somebody else... [1] http://webbackplane.com/mark-birbeck/blog/2010/02/vocabularies-token-bundles-profiles-rdfa [2] http://rdfa.digitalbazaar.com/specs/rdfa-vocab-20100111.html [3] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Feb/0055.html [4] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Feb/0053.html -- 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 vCard : http://www.ivan-herman.net/HermanIvan.vcf
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 26 February 2010 08:45:01 UTC