Re: RDFa Default Profile Management

Nathan,

So... is the problem you describe below a real problem? You bet it is. Actually, similar situation may arise with any profile. If profile 'p' includes a reference from 'foo' to 'http://bar' today and, in a few years, the authors of 'p' change the reference of 'foo' to 'http://anotherbar' then the generated triples for a file referring to 'p' will, retroactively, change. That is bad.

Let me go one step further: in some ways, I agree that profiles are bad. They bring in an uncertainty of that kind, putting the responsibility of proper vocabulary management to the publishers of profiles. I must admit that _I_ never felt the necessity of profiles for myself. I (and I presume most of us) have no problems defining the prefixes in the RDFa file which is the _only_ foolproof mechanism for URI redirection.

But. And this is a big 'but'. The sad reality is that this does not really work in practice. People will forget to put the prefix declarations, or they will screw it up my misspelling the URI-s. Hence the necessity of profiles and hence (in my view) the necessity of a default profile. Just as people do not produce valid XHTML (hence the necessity for lax rules around HTML, ie, HTML5) they do not put the namespaces either. As an example, I have looked at some pages that use the Facebook terms; even reputable sites like CNN do not do it. This example is for Facebook; but if we want a wider adoption of RDFa in HTML, then we have to rely on people forgetting this. Either we ignore the problem and then we will have lots of problems with non-valid RDFa (eg, we cannot extract triples from CNN's pages) or we construct a sub-optimal or, if you prefer, dangerous solution that would cover most of the use cases. This is where default and non-default profiles come into the picture. I hold my nose, but...

Your solution would require authors to put a @profile in their file. From that point of view, there is no difference between doing that or adding prefix declarations. It does not happen today (see CNN) what makes you think it will happen tomorrow? In my view, if we do not have a default profile, we have not solved the issue.

The next question is how would a default profile change. I think that is the responsibility of the policy of change. You say that, at (t1) there is a well known vocabulary for which there is a social convention to use the prefix "foo". Maybe what we also have to say, before we add 'foo' to the default profile, that this has to be requested by the authors of the corresponding vocabulary. That request should include a commitment of no change, ie, that 'foo' will always refer to "http://example.org/2008/02/vocabs/foo/". If the vocabulary maintainers want to make an update to .../2015/01/foo/, then they have to request another prefix, "foo2". Social conventions are not out of the blue; they are crafted and 'directed' by those who create and maintain vocabularies. If the authors of the "http://example.org/2008/02/vocabs/foo/" cannot or do not want to take a no-change commitment then, well, that particular prefix does not get into the default vocabulary. I have the feeling that by disallowing a default profile we would throw the baby out with the bath water.

Ivan


On Feb 7, 2011, at 24:59 , Nathan wrote:

> 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
> 


----
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