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

Re: foaf:sha1 property with img src=

From: Ivan Herman <ivan@w3.org>
Date: Mon, 31 Mar 2008 14:36:51 +0200
Message-ID: <47F0DAE3.7030904@w3.org>
To: Mark Birbeck <mark.birbeck@x-port.net>
CC: Dan Brickley <danbri@danbri.org>, RDFa <public-rdf-in-xhtml-tf@w3.org>
I have nothing to add to Mark's reply to Dan's original question, but 
Dan referred to more general patterns that others can just cut and 
paste. Well, the solution that Mark proposes is I think typical of an 
experience I had with other RDFa files, namely something I could call 
"if stuck, span":-). Ie, many many times, if one adds an extra <span> 
(or an extra <div>) things become simple.

Well... easy when one uses some text editor. Adding an extra span with 
extra attributes might be a bit convoluted with WSWYG editors (I have 
some hopes that, for example, Amaya will be helpful on this, the Amaya 
guys are looking at this, too...)


Mark Birbeck wrote:
> Hi Dan,
>>  I want to express the foaf:sha1 property of an image in my homepage
>>  (which already uses RDFa):
>>   From http://danbri.org/
>>  <img rel="foaf:depiction" src="danbri-txt.jpg"
>>       alt="danbri" style="float: center"/>
>>  ...this was already there, saying the picture was a depiction of me.
> @src acts like @about, not @resource/@href. So you would need to do this:
>   <span rel="foaf:depiction">
>     <img src="danbri-txt.jpg" alt="danbri" />
>   </span>
>> I
>>  want to add literal valued property of danbri-txt.jpg now, giving its
>>  hash. I was wondering if it could be done with 'rev' and 'property' but
>>  suspect it needs reorganizing with <span>...
>>  The hash of this file is
>>  $ sha1sum danbri-txt.jpg
>>  58d174f20c039289544b2364c5c21295df2e4a2b  danbri-txt.jpg
> This is the kind of use-case that made it better to have @src
> represent 'a subject' rather than an object. It means that you are now
> able to do this:
>   <span rel="foaf:depiction">
>     <img src="danbri-txt.jpg" alt="danbri"
>       property="foaf:sha1sum" content="58d174f20c039289544b2364c5c21295df2e4a2b"
>      />
>   </span>
>>  Douglas Crockford just posted a proposal for a hash= attribute in HTML,
>>  to allow user agents to cache common files like jquery.js
>>  http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=789
>>  [[
>>  Any HTML tag that accepts a src= or href= attribute should also be
>>  allowed to take a hash= attribute. The value of a hash attribute would
>>  be the base 32 encoding of the SHA of the object that would be
>>  retrieved. This does a couple of useful things.
>>  First, it gives us confidence that the file that we receive is the one
>>  that we asked for, that it was not replaced or tampered with in transit.
>>  Second, browsers can cache by hash code. If the cache contains a file
>>  that matches the requested hash=, then there is no need to go to the
>>  network regardless of the url. This would improve the performance of
>>  Ajax libraries because you would only have to download the library once
>>  for all of the sites you visit, even if every site links to its own copy.
>>  Tags: www, security
>>  Tuesday March 25, 2008 - 11:02am (PDT)
>>  ]]
> I won't comment on the merits of the idea (not because I don't think
> it's a good one, just that it makes no difference from the RDFa
> point-of-view), but there are a number of interesting aspects to this
> from the RDFa side.
> First, as we saw above this could already be implemented without
> adding a new attribute, just by using RDFa.
> Second, by using RDFa we also get more flexibility in how this is
> marked up. For example, we could just dump a whole load of hash values
> into the head of our document:
>   <html>
>     <head>
>       <title>Dan's page</title>
>       <meta about="danbri-txt.jpg" property="foaf:sha1sum"
>          content="58d174f20c039289544b2364c5c21295df2e4a2b" />
>     </head>
>     .
>     .
>     .
> Or we could even load them from an external location. So the hash
> values for particular scripts could be maintained by the script
> publishers, for example. This means that the author need not even add
> them--they could be added by a post-RDFa-parse phase.
> Third--and this one is a bit more future-oriented--I explained in
> answer to someone's question the other day about @cite, that certain
> attributes nicely follow the @instanceof model, which is that an
> attribute with a value represents a predicate and object pair. It's
> pretty easy to see how this also works for @hash, which would be
> equivalent to @property="xhv:hash". (It's a small point, I know.)
>>  BTW this brings up an old 'works manifestations expressions and items'
>>  FRBR issue with foaf:sha1 and the slippery problem of giving identity
>>  criteria for "docments"; I originally defined it as an inverse
>>  functional property, which would mean that we could conclude two objects
>>  with the same hash are 'the same thing'. Then I backed off from that,
>>  realising that for example, two different people could create zero-byte
>>  files (with same hash) on different dates; and if we had a creation-date
>>  functional property, we'd get a contradiction. But this scenario from
>>  Douglas Crockford is I think a nice use case for these ideas.
>>  http://xmlns.com/foaf/spec/#term_sha1 documents the current messy state
>>  of the property, but for purposes of this thread, can we just talk RDFa
>>  syntax first and get the notation right?
> Ok. :)
>>  ps. does anyone fancy hacking about in eg. Firefox to see about actually
>>  implementing this? could be scary deep in the core code, but would be a
>>  cool hack...
> It's an interesting idea, but my feeling is that this step would
> happen after the RDFa has been parsed, independent of how the URI was
> marked with a hash value. So that would be the first step.
> Regards,
> Mark


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Monday, 31 March 2008 12:37:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:56 UTC