Profile issues

Hi,

It's great to see the new RDFa 1.1 Core Working Draft out. The @prefix  
and @vocab attributes seem like valuable additions both to break away  
from overloading XML namespaces and enabling the use of simple terms.

The one part that concerns me is the section on RDFa Profiles. It  
concerns me on three levels: architecture, practicality and usability.  
I think it should be dropped.

Architecture
------------

The use of RDFa profiles relies on network connectivity during the  
processing of an RDFa document in order to extract the triples that  
were intended by the author of the document. This seems extremely  
dangerous, especially when combined with the rules about the  
interpretation of terms and CURIEs with unrecognised prefixes, which  
mean that the extracted RDF is not a simple subset of that which would  
be otherwise generated, but one that includes bogus triples.

Let's say that I have a simple document like:

<div prefix="my: http://www.w3.org/2006/vcard/ns#">
   <p about="http://www.example.org/doc"
     profile="http://www.example.org/profile"><span  
property="my:title">title of the document</span> <span  
property="rdfs:comment">and this is a longer comment on the same  
document</span></p>
</div>

Let's say that the profile document binds my: to the Dublin Core  
namespace and rdfs: to the RDFS namespace. You will get:

   @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
   @prefix my: <http://dublincore.org/documents/dcmi-terms/> .
   <http://www.example.org/doc>
     my:title "title of the document" ;
     rdfs:comment "and this is a longer comment on the same document" .

Now what if the profile document isn't there for some reason? You get:

   @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
   @prefix my: <http://www.w3.org/2006/vcard/ns#> .
   <http://www.example.org/doc>
     my:title "title of the document" ;
     <rdfs:comment> "and this is a longer comment on the same  
document" .

You can argue that the triple with the <rdfs:comment> property isn't  
ever going to be looked at, but with the my:title triple, the meaning  
is both plausible and significantly different in the two cases.

If profiles aren't dropped, I'd suggest either:

   * ignoring all triples in the scope of a profile that hasn't been  
successfully retrieved
   * placing those triples within a separate RDF graph

Practicality
------------

As someone who's interested in implementing RDFa processing within the  
browser, the immediate thing that struck me was how difficult it would  
be to implement RDFa profiles because of the same origin policy in  
current and legacy browsers.

I anticipate arguments that browsers will 'soon' implement a built-in  
RDFa API and/or the Origin header. Given the slow pace of change with  
browsers (or the slow adoption of updated versions), I don't think we  
should take this for granted at all. I feel that stalling support for  
RDFa within the browser by making it basically unimplementable would  
be a bit mistake.

Building in profiles, as suggested in a Note within the profiles  
section) is also not an answer, given that the profiles may change.  
Effectively, processors *must* hit the profile URI each time at least  
with a HEAD request to see whether the profile has changed, and that  
isn't possible with Javascript.

If profiles aren't dropped, I'd suggest making the access of profiles  
optional (perhaps by having different levels of conformance), and  
providing one of the facilities described above to ensure that such  
processors aren't completely unusable in those circumstances.

Usability
---------

My final concern is about the usability of RDFa when profiles are  
introduced. If two profiles both contain mappings of the same term,  
then the ordering in which they are listed within the profile  
attribute will determine the meaning of that term when it's used  
within RDFa.

This is a basic problem with using terms, really (because terms aren't  
namespaced and can therefore clash), but I think that putting their  
definitions into a separate file will make clashes harder for people  
to identify.

These problems are exacerbated when individual profiles might not be  
accessible, and thus a particular term can mean completely different  
things on different occasions.

I don't see any way around this, frankly. All in all, I think that  
RDFa profiles should be dropped.


That's all,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Thursday, 29 April 2010 16:05:09 UTC