- From: Nathan <nathan@webr3.org>
- Date: Sun, 06 Feb 2011 23:59:06 +0000
- To: RDFa Working Group <public-rdfa-wg@w3.org>
- CC: Manu Sporny <msporny@digitalbazaar.com>
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