W3C home > Mailing lists > Public > public-swd-wg@w3.org > July 2007

Re: [RDFa] ISSUE-42: the @src attribute

From: Niklas Lindström <lindstream@gmail.com>
Date: Thu, 19 Jul 2007 16:38:16 +0200
Message-ID: <cf8107640707190738u60f995e3lc89c20a6267ad193@mail.gmail.com>
To: "Ben Adida" <ben@adida.net>
Cc: mark.birbeck@x-port.net, RDFa <public-rdf-in-xhtml-tf@w3.org>, "SWD WG" <public-swd-wg@w3.org>

Ben, Mark, Ivan, all.

Ben, this sounds quite reasonable to me. Thank you for the elaboration
of the proposed rules.


== Examples ==

I'd like to try it out with some examples. It seems to work with needs
of e.g. relating "compound" parts of a document, like:

    <div id="article_1" instanceof="law:Article"> ... </div>

to yield:

    <#article_1> a law:Article .

Does it mean that this:

    <div id="article_1" rev="law:article"> ... </div>

still (IIRC) yields:

    <> law:article <#article_1> .

as well? When you say "the element's corresponding RDF identity is
also the object of any @rel, or the subject of any @rev", it seems it
is not?

And furthermore, would:

    <div id="article_1" rev="law:article" instanceof="law:Article">
        <h3><span property="law:articleOrdinal" xml:lang="">1</span> §</h3>
        ...
    </div>

give me (along with the statements above):

    <#article_1> law:articleOrdinal "1" .

, or do I still need @about as well? I think there may be some
difficulty in determining the current subject, since today, AFAIK, it
is inherited from @about, @id means something to @rel/@rev of direct
children, and blank nodes I suppose are inherited? I realize I am
confused by this right now, and perhaps this discussion we're having
could affect the premises (algorithm)?


== The @id ==

Perhaps it's the limited "subjectification" of (the URI corresponding
to) an @id that throws me off.

The need for duplicated @about for elements with @id is another issue
I was about to leave.. But it just looked so tempting to have triggers
for making an @id work like @about (setting the subject for
descendants).. I'm uncertain where we are now with @id, will @rel/@rev
use it if they belong to elements being the direct child of the
identified element - always so and never more? Or was this limited to
the now non-available meta and link in body?

I recall reasons for this (similar to doubts about @role and @class,
that is avoiding accidental misinterpretations of the host markup),
which may also apply to e.g. blank nodes? But if these were to be
inherited, that (subject) could always be "reset" with e.g. @about="",
right?

I must refresh my memory on this, I just wanted to voice my concerns
in case they are of importance. I hope I don't cause confusion in the
process.


== Going forward ==

"It also seems to make sense when I look at the markup, though [...]".
Ben, I do believe this:

    - if it makes sense when looking at the markup, it may be right
    - if it does not, it is probably wrong

;)

I also believe (in alignment with Ivan) that this algorithm is in need
of a full write-up, so we can test our edge cases against it. Maybe
this could continue under another thread, say "The corresponding RDF
identity"? To deal with the correlated questions about:

    - how striping is achieved with @id (if ever), @about and (if at
all or when) @resource, bnodes
    - what @instanceof applies to (in light of what this is sugar for,
if it's not special)
    - how to express blank nodes (including Ivan's "_:" suggestion)
    - on the fringe effecting possible solutions to RDF lists etc.

What do you think?


Best regards,
Niklas



On 7/19/07, Ben Adida <ben@adida.net> wrote:
>
>
> Mark,
>
> I think I like what you're saying... I'm still processing it.
>
> The one thing I disagree with is what happens with the following markup:
>
> <div about="#foo" instanceof="foo:bar">
> </div>
>
> I think it *should* result in
>
> <#foo> rdf:type foo:bar .
>
> I don't think that much change is needed from what you're suggesting,
> though. I've just implemented the following rules in my RDFa JavaScript
> parser, and it looks like it works relatively well:
>
> - Consider the concept of an HTML element's "corresponding RDF identity".
>
> - the "corresponding RDF identity" is determined as follows:
>   - @resource takes precedence
>   - if no @resource, @href is next
>   - if no @href, then @id.
>   - if no @id, then @about.
>   - if all else fails, a bnode.
>
> - the element's corresponding RDF identity is the subject of an rdf:type
> triple when instanceof appears.
>
> - the element's corresponding RDF identity is also the object of any
> @rel, or the subject of any @rev.
>
> - the subject of a @rel, or the object of a @rev, is determined using
> the normal @about rules.
>
> - the subject of an element's *content* is the element's corresponding
> RDF identity when @rel, @rev, @href, @resource, or @instanceof appears.
> Otherwise, it's @about resolution.
>
>
> We will clearly discuss this tomorrow, but I wanted to lay this out
> because I think this works, and with all existing markup still
> consistent. It also seems to make sense when I look at the markup,
> though I know that carries little weight :)
>
> -Ben
>
> Mark Birbeck wrote:
> > Hi Ivan,
> >
> >> Indeed, how do I then set the rdf:type for the _subject_?
> >
> > Yes...I apologise for jumping the gun and making it sound easier than
> > it is. I realised the same thing as you a few hours after I sent my
> > post. In my case I was looking at a use-case that I'm really keen on,
> > which goes like this:
> >
> > A normal link in your blog might look like this:
> >
> >  I found a good recipe in
> >  <a href="http://www.amazon.com/gp/product/0091808189">
> >    Canteen Cuisine
> >  </a>.
> >
> > This is fine as a link to a book, but from the point of view of
> > improving the web :) it's not great. Ideally we want to just put an
> > 'identifier' in there for the book, and then let people do whatever
> > they want to with it--buy it from a bookshop, add it to their
> > wish-list, search for other books by the same author, and so on.
> >
> > This was quite straightforward with our old syntax, and a few months
> > ago I blogged about how great it was that we could use this syntax:
> >
> >  <span xmlns:bib="http://somebig.org/" about="urn:ISBN:0091808189"
> > class="bib:book">
> >    Canteen Cuisine
> >  </span>
> >
> > Which gives me this triple:
> >
> >  <urn:ISBN:0091808189> rdf:type <http://somebig.org/book> .
> >
> > Now, as you rightly say Ivan, the problem is that we've recently
> > started to define our rdf:type shorthand as being applied to the
> > _object_ of a statement. And what's more, we've even started to say
> > that if there is no object one should be created. In other words, if
> > we have this:
> >
> >  <span instanceof="bib:book">
> >    Canteen Cuisine
> >  </span>
> >
> > we get:
> >
> >  _:span0 rdf:type <http://somebig.org/book> .
> >
> > And again, as you point out, even if we add an @about:
> >
> >  <span about="urn:ISBN:0091808189" instanceof="bib:book">
> >    Canteen Cuisine
> >  </span>
> >
> > we don't get the triples I had earlier, unless we were to add some
> > convoluted rules to say when @instanceof applies to the bnode and when
> > to the @about.
> >
> > However, if we go back for a moment the original mark-up, i.e., the
> > normal way to do a link:
> >
> >  <a href="http://www.amazon.com/gp/product/0091808189">
> >    Canteen Cuisine
> >  </a>
> >
> > We see it's usual to have a resource with no @rel value--i.e. nothing
> > going 'upwards' to connect this to the containing document. Also, if
> > we look at the triples I want:
> >
> >  <urn:ISBN:0091808189> rdf:type <http://somebig.org/book> .
> >
> > you can see that they have no relationship to the containing document;
> > I'm saying saying that 'x' is a book, which then allows the software
> > to do all sorts of clever things with the identifier.
> >
> > Given these two things, why don't we just make this the best practice:
> >
> >  <span resource="urn:ISBN:0091808189" instanceof="bib:book">
> >    Canteen Cuisine
> >  </span>
> >
> > It follows the same pattern as @href, I think.
> >
> > Now, you could say that this will cause confusion over when to use
> > @resource and when to use @about, but if (and it's a big 'if'...but
> > not an impossible 'if') we go with the idea that Ben is suggesting, of
> > resurrecting the idea that the object (if it's a resource) sets the
> > subject for the context, then we would have a situation where the
> > following would be perfectly legitimate:
> >
> >  <span resource="urn:ISBN:0091808189" instanceof="bib:book">
> >    Canteen Cuisine was written by
> >    <span property="dc:creator">Marco Pierre White</span>
> >  </span>
> >
> > In other words, in a world where 'the object sets the subject',
> > @resource would be more commonly used than @about, and I think
> > probably the only reason you'd need to use @about would be if you
> > wanted to put a subject and resource object on the same element.
> >
> > Of course, it depends on how we go with resurrecting the 'chaining'
> > approach from the original drafts, but if we do go that way, it saves
> > having to have two attributes.
> >
> > One last thing that people might like to ponder; we discussed on last
> > week's telecon how we'd all like to see browsers that are able to make
> > use of metadata to create 'smart links' to other resources. (The
> > discussion was in the context of whether we needed @resource, or if
> > @href was sufficient.) It strikes me that changing the above mark-up
> > one more step, so that the <span> is replaced with <a>:
> >
> >  <a resource="urn:ISBN:0091808189" instanceof="bib:book">
> >    Canteen Cuisine
> >  </a>
> >
> > might be one way to do it.
> >
> > In this mark-up, the author is effectively saying that they want some
> > kind of interactive location to be created (denoted by the <a> tag).
> > But what 'interactivity' is placed there will depend on an array of
> > factors, such as the browser's capabilities, the user's preferences,
> > and so on. We might end up with a personalised menu of links and
> > actions such as 'add this book to my wish-list', but the main thing is
> > that the author is indicating that the information the browser should
> > use to create this 'menu of links' is the identifier
> > 'urn:ISBN:0091808189'.
> >
> > This would mean that there is also a difference between this:
> >
> >  <a href="http://www.amazon.com/gp/product/0091808189">
> >    Canteen Cuisine
> >  </a>
> >
> > which creates a direct link to a web-page, and this:
> >
> >  <a resource="http://www.amazon.com/gp/product/0091808189">
> >    Canteen Cuisine
> >  </a>
> >
> > which creates a cluster of actions and links that are relevant to that
> > web-page.
> >
> > That's in the 'interesting...but for the future' category, but I
> > mention it because it makes me feel that we're heading in the right
> > direction with some of the newer things we've decided.
> >
> > Regards,
> >
> > Mark
> >
>
>
>
Received on Thursday, 19 July 2007 14:38:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:29 GMT