Re: finding closure on the issues

Hi Ben/Dan,

There is an option (c) for @src behaviour, which is the option that
emerges from my chaining rules. The rules say that @src can be both a
subject or object, so both scenarios would be possible. (This is the
source of the prior confusion, where I thought that the proposal for
@src behaving like @about was consistent with these rules, which led
to me supporting it.)

Anyway, I'd like to try a different way of explaining the whole
chaining-RDFa-subject-object-thing, that might help.

It goes something like this:

  * imagine a 'minimal' RDFa that only has @about, @instanceof and
    @rel -- that's enough to do chaining, as well as to set rdf:type;

  * but then imagine that we wanted to be more 'concise', and express
    a triple on one element -- we therefore add another attribute;

  * so now we have @about, @instanceof, @rel and @resource, and
    the rules are simply that @resource is exactly the same as @about,
    except when @rel is present, and then @about goes to the left of
    @rel and @resource goes to the right;

  * the rule for @instanceof, by the way, is that it always applies to the
    subject on the element, however determined. In other words, if there
    is no @rel present, then @instanceof has no favouritism, and will
    apply to any attribute that indicates a resource. But when @rel is
    present, @instanceof always goes for the subject (i.e., it binds to
    the attribute that 'shifts left').

So, we now have a set of generic rules, and any new attribute that is
added to RDFa has to follow these rules (i.e, it will act like one of
the attributes @about, @instanceof, and @resource).

Firstly, a new attribute has to follow the generic rules, in that if
no @rel is present it will act just like @about and @resource do, in
that they set the subject and object of triples down the tree, as well
as working with @instanceof.

And secondly, the new attribute has to provide a specific rule, and
indicate how it should act in the presence of @rel: will it go to the
left of @rel (like @about) or to the right (like @resource)?

That's it! There really is nothing more to it than that -- an
attribute can't behave in any other way than @instanceof, @about or
@resource. (Ok...@content, @datatype...I know...but let's stick to the
core of RDFa and RDF, which is resources.)

So for any language that you care to look at, i.e., a language that
you might want to put RDFa into, you only need these rules. (Actually,
we also need to know what happens if more than one attribute is vying
for a particular position, but there are only two choices -- take all
possible permutations, or have an order of precedence , and we've
adopted the latter, so we can ignore that for now.)

So, let's now apply these rules to the XHTML attributes that deal with
resources:

  * @href is easy -- it has to go to the right of @rel since XHTML
     already says so;

  * @src has no precedent, so we could define it whichever way we
     see fit.

Which way you would prefer @src to go (left or right), is determined
by whether you think it is more common to say that some item 'x' is in
a relationship with an image, or some image is in a relationship with
'x'. For example, the former would be most useful when dealing with
FOAF:

  <img about="#me" rel="foaf:img" src="ben.jpg" />

but the latter would be more useful when dealing with CC licenses:

  <img src="ben.jpg" rel="cc:license" resource="http://...attribution" />

Note that in this generic model, this decision is unrelated to the
issue raised about setting rdf:type for an image, since the 'core
rules' apply to all attributes, including @src, so the following will
'just work':

  <img src="ben.jpg" instanceof="foaf:Image" />

In my model of chaining the debate about @src only needs to be about
which side of @rel it should go when @rel is present: left or right.


The other three issues that remain then (and I'm now going to put the
issues into language that is consistent with the model I've described
above), amount to whether some of the attributes being added to RDFa
should have behaviour that is different to the 'core' or 'generic'
rules, and instead have specific rules defined for them, as follows:

  * when there is no @rel present on the same element as an @href,
    @src, or @resource, then neither should behave like objects;

  * when there is no @rel present on the same element as an @href,
    @src or @resource, then neither should behave completely like
    subjects:

    * whilst they can still set the subject for nested statements...

    * ...@instanceof will NOT apply to them.

Note that this is quite a fundamental change from the processing model
I thought I'd won support for; instead of talking in terms of general
concepts like subjects and objects (for example, saying things like
"@instanceof applies to 'the subject'"), we instead have to make the
rules 'aware' of the attributes that carried them (for example,
"@instanceof applies to @about or creates a bnode".

The third issue (in case you only counted two there) relates to Ben's
suggestion that that @resource can set the subject for nested
statements even if @about is present on the same element. That changes
not only the core rules, but also very long established rules. In my
model the only attribute that changes how other attributes behave is
@rel (and by extension @rev):

  * in the absence of @rel, an element contains one subject/object
    item, and @about takes precedence using the normal precedence
    rules;

  * in the presence of @rel an element could have two subject/object
    items, one to the left of @rel, and one to the right, and precedence
    rules would apply to each 'slot'.

If we allow an @about and @resource on the same element to create two
subject/object pairs, even without a @rel, then we're losing yet more
genericity.


Anyway, I don't know if this has helped or not. The only reason I
thought it might, was that I explained my parsing model in a similar
manner on the telecon last week, and Manu said it helped him
understand it better. I concluded therefore that either there is some
merit in this way of explaining things, or that both myself and Manu
have equally distorted mindsets.

I'm not asking anyone to vote on that last point. :)

Regards,

Mark


On 21/01/2008, Ben Adida <ben@adida.net> wrote:
>
> Dan Brickley wrote:
> > Do you have a pointer to a brief summary of each? (test cases would be
> > sweet too :)
>
> Manu did a good job here on @href/@resource completing @rel:
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Jan/0095
>
>
> On the @src issue, here's a summary independently of the first issue:
>
>
> OPTION (a): @src is equivalent to @href/@resource and is overridden by
> them (what we had until 3-4 weeks ago):
>
> <div about="#me">
>   <img rel="foaf:img" src="ben.jpg" />
> </div>
> =======
> <#me> foaf:img <ben.jpg> .
>
>
> OPTION (b): @src is equivalent to @about and can thus be used with
> @instanceof
>
> <div about="#me" rel="foaf:img">
>   <img src="ben.jpg" instanceof="foaf:Image" />
> </div>
> ========
> <#me> foaf:img <ben.jpg> .
> <ben.jpg> a foaf:Image .
>
>
> The issue with (a) is that you can't declare a type on an image and that
> @src/@href/@resource are all the object, which gets a bit odd. Also,
> @src and @href are both HTML attributes that imply inline-inclusion and
> linkability, and I'm not sure one should override the other.
>
> The issue with (b) is that the nice markup of @rel and @src on an IMG
> tag goes away. The other issue is that any image inside a hanging @rel
> completes it.
>
> -Ben
>
>


-- 
  Mark Birbeck, formsPlayer

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

  standards. innovation.

Received on Tuesday, 22 January 2008 00:44:42 UTC