Re: Profile issues

This issue has been discussed by the group and we did have a resolution on going ahead with @profile. But Jeni's email does include a new element that we may want to consider: she proposes that if, at some element, @profile cannot be dereferenced, then the whole subtree would be taken out of RDFa processing. (It is a fairly drastic move but makes a lot of sense in my view.)

Should we add this as an official issue to our list?

Ivan




On Apr 29, 2010, at 18:04 , Jeni Tennison wrote:

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


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