Re: The implied @about="": Explanation and some problems

Mark,

Lengthy example and discussion below. I think that two RDFa quirks --  
the implied @about on //head and //body, and its use of //base to  
determine the default subject -- combine into something quite  
unfortunate and confusing.

On 1 Apr 2009, at 15:05, Mark Birbeck wrote:
>> But this has the effect that in RDFa, the subject no longer  
>> defaults to the
>> URI of the *page*, but to the URI of *another page*, which is  
>> usually not
>> what I want (I want my @property="dc:title" and  
>> @rel="foaf:primaryTopic" to
>> apply to the individual page, not to the homepage).
>>
>> So I need to override the <base> with @about in order to have the  
>> desired
>> default subject in RDFa. But because the implicit @about="" is  
>> added *twice*
>> (at <head> and <body>), I also need to override it *twice*.
>
> I agree that this sounds right...but when I think back to examples
> where I've done this kind of thing, I recall that I've invariably
> created a bnode for the body anyway, since what the document is
> 'about' is different to the document itself. (That's the information
> resource/resource issue I referred to.)
>
> In other words, the general subject for statements in the body is
> usually different to the general subject for statements in the head,
> particularly when using foaf:primaryTopic.

Okay, first an example without <base>:

<!-- This is http://mysite.com/projects/xyz.html -->
<html>
   <head>
     <title>My Site - Project XYZ</title>
   </head>
   <body>
     <h1>Project XYZ</h1>
     <p>Something I did last year.</p>
   </body>
</html>

I want four triples:

    <http://mysite.com/projects/xyz.html> dc:title "My Site - Project  
XYZ" .
    <http://mysite.com/projects/xyz.html> foaf:primaryTopic <http://mysite.com/projects/xyz.html#it 
 > .
    <http://mysite.com/projects/xyz.html#it> rdfs:label "Project XYZ" .
    <http://mysite.com/projects/xyz.html#it> rdfs:comment "Something I  
did last year" .

To me, it seems pretty intuitive to add this markup, and it works:

    @property="dc:title" on //title
    @rel="foaf:primaryTopic" on //body
    @resource="#it" on //body
    @property="rdfs:label" on //h1
    @property="rdfs:comment" on //p

Now, if we have a <base> element:

    <base href="http://mysite.com/" />

This breaks the subject of dc:title and foaf:primaryTopic, and the  
relative <#it> resolves to the wrong absolute URI (</#it> instead of </ 
projects/xyz.html#it>).

Now, the first idea would be to add

    @about="projects/xyz.html" on //html

That seems straightforward enough, and someone who knows little about  
RDFa would probably assume that this fixes the subject of dc:title and  
foaf:primaryTopic, and *might* assume that it also fixes the base for  
<#it>. But it doesn't work.

Instead I need:

    @about="projects/xyz.html" on //head
    @about="projects/xyz.html" on //body
    @resource="projects/xyz.html#it" on //body (instead of  
@resource="#it")

This solves the problem, but feels awkward to me.

Another option would be to produce the foaf:primaryTopic triple like  
this:

    @about="projects/xyz.html" on //head
    @about="projects/xyz.html#it" on //body
    <link rel="foaf:primaryTopic" resource="projects/xyz.html#it" />

This is probably what you were thinking of? It feels better than the  
previous option, but it's less obvious because we add some no-op HTML  
markup in order to produce RDFa triples.

Some of the discomfort comes from the fact that the base URI, rather  
than the document URI, is used as the default. In pure HTML, and thus  
in most web developers' mental model, the base URI determines  
*resolution of relative URIs*, but nothing else. It does not change  
the URI of the current page. It does not affect the URI that you see  
in the browser bar, or the value of document.location in Javascript,  
or what gets saved when you bookmark the page. The base URI in plain  
HTML is really just about resolving relative URIs. But in RDFa,  
specifying a base URI changes what is considered the URI of the  
document. This is running deep. The RDFa primer is full of examples  
that would break if a base URI is declared in the page (e.g.  
rel="license", which suddenly applies to the base URI rather than the  
current page as probably intended).

So, most likely, if you declare a base URI, you will have to remember  
to change it back to the current page URI in //head and //body, or you  
will get confusing or unintended triples. The fact that you cannot  
simply change it by declaring @about on //html makes matters worse. I  
found this a major gotcha when building my first RDFa-enabled site  
(prefix.cc).

I don't know what would improve the situation, and totally expect to  
be proven wrong here, but my gut feeling is that //base should not be  
used in determining the default subject. The default subject should be  
the document location, minus fragment. Any *explicit* @about="" would  
of course, per relative URI resolution rules, still expand to the base  
URI if one is defined.

And I think that the invisible default @about should go on //html.

My gut feeling about an implied @about="#", as you proposed earlier,  
is that it would just add more confusion, better leave it to the  
author to choose a fragment for their page's topic if they want to. An  
implied @about="#" would just make authors go: "Yeah sometimes it  
appends a '#' to the URI, I don't know why it's doing it, I think it  
doesn't matter." If someone understands why they should have a  
fragment on the URI for their topic resource, then they will find it  
easy enough to make it happen.

All the best,
Richard


>
>
> But perhaps the best thing, before we jump to any conclusions, would
> be if you could provide an example? Then we could take it from there.
>
> Regards,
>
> Mark
>
> -- 
> Mark Birbeck, webBackplane
>
> mark.birbeck@webBackplane.com
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)

Received on Wednesday, 1 April 2009 15:29:54 UTC