W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2008

Re: RDFa test suite addition

From: Dan Brickley <danbri@danbri.org>
Date: Tue, 29 Jul 2008 09:16:44 +0200
Message-ID: <488EC3DC.3020703@danbri.org>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>

Manu Sporny wrote:
> Mark Birbeck wrote:
>> That's fine, and simply 'appending' will work in this situation,
>> provided -- as you say -- that you append to the correct part of the
>> base URL.
> Right, I didn't mean to imply that 'appending' will work in all cases
> (even though I'm not convinced that the statement is not true).
> What you have said has got me wondering about what is correct,
> acceptable and incorrect, however.
>> But we also need to ensure that the same triples are generated by this:
>>   <div about="#sneaking-sally">
>>     <a rel="media:download" href="../../live/sneaking_sally.mp3">Live
>> Recording</a>
>>   </div>
>> The sample document you gave is in the directory "/fuzzbot/demo", so
>> "../../live" should be the same as "/live". However, even if you
>> 'append to the right part', the resulting URL is wrong:
>>   <http://rdfa.digitalbazaar.com/fuzzbot/demo/../../live/sneaking_sally.mp3>
> I realize that the URL above is not optimal, but is it "wrong"? RFC-1738
> says that the URL is valid (if I'm reading the RFC correctly):
> ftp://ftp.isi.edu/in-notes/rfc1738.txt
> Is it the RDFa parser's job to normalize URLs? I can certainly see the
> argument for why it should tidy up URLs, but I don't think this is a MUST.
> If it's not a MUST, then we find ourselves in a position where the
> application/inference engine MUST normalize the URLs coming in from the
> RDFa parser.

Please let's have the parser do this. Very few RDF toolkits do any kind 
of URI normalisation (eg. stripping :80, downcasing hostnames). I don't 
see this changing in a hurry. So this would leave the work in the hands 
of each app developer. Let's say 30% don't bother doing it, 30% do it at 
least partly wrong, and 40% do it right. That scenario (+/- 10% maybe) 
is hardly likely to encourage publishers to rely on using '../..' in 
RDFa, even though many HTML sites and tools currently use it.

I doubt more than twenty or thirty people will be writing RDFa parsers; 
and amongst those, a good number will be copying and transliterating 
code written by others in a different scripting language. Asking these 
folk to do this little extra bit of work will benefit both app 
developers and content publishers, since they will have much greater 
confidence that the widely used "../../foo.bar" idiom is useful in an 
RDFa context.



Received on Tuesday, 29 July 2008 07:17:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:28 UTC