RDFa Default Profile Management

Hi All,

This relates to ISSUE-73 and ISSUE-78 , during a recent telecon I voiced 
some concerns about "default profile" management.

For the sake of example, let's suggest that at this time (t1) there is a 
well known vocabulary for which it is social convention to use the 
prefix "foo:", and thus we add the following to the "default profile".

   [] rdfa:prefix "foo:" ;
      rdfa:uri "http://example.org/2008/02/vocabs/foo/" .

As time progresses, there are a few things that can easily happen here:

  1: People stop using that vocabulary
  2: The vocabulary is updated (foo 1.1, foo 2) and referenced by a new URI
  3: Social convention changes such that people start using "foo:" to 
refer to a different vocabulary

Let's suppose, that at a time in the future (t2), either (2) or (3) has 
occurred, and that a document created at t1 relies on the default 
profile, and likewise another document at t2; and that neither document 
specifically references the default profile, that is, the RDFa 
processor/parser incorporates the default profile.

If we do not change the default profile, the document created at t2 will 
have incorrect triples created.

If we do change the default profile, the document created at t1 will 
have incorrect triples created.

If we release a new versioned default profile with the new mapping in 
it, and processors incorporate this new profile, then the document 
created at t1 will have incorrect triples created.

If we release a new versioned default profile with the new mapping in 
it, and processors /do not/ incorporate this new profile, then the 
document created at t2 will have incorrect triples created.

To address this, it is my assertion that:

  - the notion of "default profile" should be dropped
  - parsers should not implement or make use of any profile that is not 
specified by the document
  - an RDFa 1.1 profile should be created, and must /never/ change.
  - the RDFa 1.1 profile may be cached or hard coded in to RDFa 1.1 
processors.
  - if document authors want to make use of the RDFa 1.1 profile then 
they must specifically include reference to it.

If however an RDFa version indicator was included in RDFa 1.1, then I'd 
assert that:
  - an RDFa 1.1 profile should be created, and must /never/ change.
  - the RDFa 1.1 profile may be cached or hard coded in to RDFa 1.1 
processors.
  - RDFa processors should consider the RDFa 1.1 profile as the 'default 
profile' for all RDFa documents bearing the RDFa version of 1.1
  - if document authors want to make use of the RDFa 1.1 profile then 
they should specifically include reference to it.

In both cases, the RDFa Core 1.1 specification would explicitly state 
the prefixes which 1.1 processors should recognise and provide default 
mappings for, and that these are also provided in a downloadable "RDFa 
Core 1.1 Profile".

Overall, I'm saying that the only circumstance we could/should provide a 
"default profile" is if RDFa is specifically versioned and one profile 
is provided per version of RDFa.

Personally, I think it would be far wiser to drop the notion of "default 
profile" and instead release a profile which /authors/ may reference and 
make use of if they wish - to me it makes far more sense to encourage 
authors to make use of well defined shared profiles, rather than 
encouraging them to make "mistakes" and for processors to try and patch 
up the mistakes by assuming the authors meant <uri> when they said "foo:".

Finally, whilst I think shared profiles of common terms and prefixes 
will be extremely useful and beneficial to the RDF(a) communities, I 
have to say that I have many reservations and concerns about the current 
approach taken in RDFa Core; however, the response above applies to 
whatever approach we ultimately take for profile functionality.

Best,

Nathan

Received on Sunday, 6 February 2011 23:59:48 UTC