W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

RDF or key-value pairs (on ISSUE-1)

From: Ivan Herman <ivan@w3.org>
Date: Mon, 15 Mar 2010 19:22:07 +0100
Message-ID: <4B9E7ACF.8070409@w3.org>
To: W3C RDFa WG <public-rdfa-wg@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.


[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

Received on Tuesday, 16 March 2010 10:29:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:46 UTC