Re: foaf:sha1 property with img src=

Hi Dan,

>  > @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>
>  >
>
>
> Ah. Was my original markup wrong then? Or just not extensible to this
>  new sha1 need

It was wrong. :) We only finalised the 'is @src a subject or an
object' issue just before we released the draft, so it's our fault,
not yours.


> > 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>
>  >
>
> Thanks. Homepage updated! I've also added jquery to my homepage, and the
>  hash for that specific jquery into the <head> using meta as you mention
>  below.

Great.


>  BTW can I jump in here before an example spreads further: the property
>  is foaf:sha1 not :sha1sum. We do have a mailbox identity property called
>  foaf:mbox_sha1sum but feedback was that this was a bit wordy, so when
>  foaf:sha1 was added we went the short route (yes, at the cost of
>  internal consistency...).

Oops...sorry! I knew that, but when I cut-and-paste the actual SHA1
value, I also took the command-line you had used to generate it, and
then turned that into a predicate......


>  Here is the RDFa N3 I get from my homepage now, using the development js
>  parsing bookmarklet:
>
> [...]
>
>
>  Seems right :)

Yep...looks good to me, too.


> > First, as we saw above this could already be implemented without
>  > adding a new attribute, just by using RDFa.
>  >
>  >
>
> Yes, that's rather nice huh? :)

Indeed. :)


>  RDF isn't always an agent of complication!

Ha...! Not anymore. :)


>  Could I have done this instead?
>
>   <script type="text/javascript" src="jquery-1.2.3.min.js"
>    property="foaf:sha1"
>  content="6463e558dd79d51a2e8464806824c7bbc18c77fd"></script>

No reason why not. The parsing rules don't prohibit it, and it's an
even neater way to do this.


>  > 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.
>  >
>
> Maybe they could be loaded and remembered from site-wide metadata but
>  that's a bit advanced (and not peculiar to RDFa; rdf/xml would work
>  there). Or perhaps I don't follow you.

No...that's exactly what I meant; that since RDFa is RDF, then it
doesn't matter where we get the information from.


> > 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.)
>  >
>  >
>
> It's the same conceptual model, yup. Are you suggesting that in the
>  future, properties could be automatically generated for these?

It's only early days, and it comes from some ideas I was bouncing
around when I did some work for the IPTC. In that context it felt
'right' that any prefixed value should become a predicate, much like
an element does in RDF/XML.


> >>  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
>
>
> We'd need to know more about when Firefox initiates requests for
>  dependent resources (css, js, images); if this is incremental, we'd need
>  RDFa parsing to be happening then too, otherwise waiting til page load
>  is complete could slow things down. But there we get into issue of
>  different behaviours between XHTML and HTML maybe, since XML needs a
>  full document to work on, not a stream...

It is definitely incremental in HTML, and although it isn't in XHTML,
there is no reason it couldn't be. So you are right that this wouldn't
be easy. Long term I'd like to see the metadata 'aspect' of the DOM
interwoven with the DOM itself. Adding or removing attributes on the
DOM, would then automatically change the metadata that the DOM
represents. It would be as if the is another layer to the InfoSet, for
metadata.

But one thing at a time. :)

Regards,

Mark

-- 
  Mark Birbeck

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.x-port.net | http://internet-apps.blogspot.com

  x-port.net Ltd. is registered in England and Wales, number 03730711
  The registered office is at:

    2nd Floor
    Titchfield House
    69-85 Tabernacle Street
    London
    EC2A 4RR

Received on Monday, 31 March 2008 13:24:17 UTC