- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 15 Mar 2010 19:22:07 +0100
- To: W3C RDFa WG <public-rdfa-wg@w3.org>
- Message-ID: <4B9E7ACF.8070409@w3.org>
Hi guys, It may well be that by the time this mail gets to the mailboxes this issue will have been solved; sorry about that. The fact is that I write this mail on the plane en route to Boston... That is also the reason why I do not put references in my mails, I cannot find the URI:-( I would like to come back to the issue whether we define the keyword/prefix mapping via key value pairs like Mark had or via RDF statements like I said. One of Mark's comments in one of his mail made me think, namely we will have to properly define the vocabulary that may not be that easy. And I realized that what is in the document I had[1] (and, I believe, was also in Manu's document) is modelling-wise wrong, at least in my view. Indeed, I had written something like <uri-for-foaf> rdfa:prefix "foaf" . <uri-for-foaf-name> rdfa:keyword "name" . (Keeping the two notions separate at least for the sake of the discussion). This is wrong, because we should _not_ make a statement on the resource for foaf, we would just like to make some statements on the URI as a string. Otherwise, if there are two vocabulary files in RDF on the web, both making statements on the same resource than, in an RDF worlds, both are fine, right? But what happens if there are contradictions, ie, two different vocabulary files would use contradictory terms? We would create a mess on the Web. That is wrong. As a consequence, the correct way of modelling this is something like [ rdfa:uri "http://uri-for-foaf" ; rdfa:prefix "foaf" ] [ rdfa:uri "http://uri-for-foaf-name" ; rdfa:keyword "name" ] which is, of course, pretty close to what Mark described (coincidentally, including on the syntax...). If we decide to add restrictions to keywords, ie, on what attributes they can be used, this is easy to add; we could have [ rdfa:uri "http://uri-for-foaf-name" ; rdfa:keyword "name" ; rdfa:keywordRestriction "rel", "rev" ] which is an easy additional step. So should we abandon RDF for this? _That_ step I did not make (Mark would probably add 'yet'?). Using RDF, like above, means that we can use an existing syntax (eg, RDFa:-) to encode it, nothing extra is needed for users or for implementers. The other point is that it is possible to describe the vocabulary using a little bit of OWL such that a number of restrictions are properly defined. I attach a first attempt for such a vocabulary file. This describes (hopefully) issues like: - the value for a keyword, a prefix etc, must be a NMTOKEN - the value for rdfa:uri must be a URI (of course) - rdfa:uri is a functional property, ie, I cannot have structures like [ rdfa:uri "uri-1", "uri-2" rdfa:prefix "name" ] - I added some extra restrictions, like keyword/prefix being also functional, ie, [ rdfa:uri "uri-1"; rdfa:prefix "name1", "name2" ] (Although we could live with such (messy) thing, but it is ugly to mix these.) I have also put there the fact that the keyword and the prefix mapping should not be mixed up with one (bnode) structure. At the least such restrictions may make the life of implementations easy; simple OWL processors can also check the consistency of a specific vocabulary. (As far as I can see, an OWL RL processor[2], ie, a simple rule engine implementation of a specific OWL Profile, can also handle it.) Just food for thoughts... But, in any case, even if we keep to the usage of RDF, the version on the web right now is wrong. Ivan [1] http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100311/ [2] http://www.w3.org/TR/owl2-profiles/#OWL_2_RL -- 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
- text/plain attachment: rdfa.ttl
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 16 March 2010 10:29:19 UTC