Re: Thoughts on @href/@resource completing hanging @rels

Hi Ivan,

This was indeed useful...thanks. :)

> [...]

> Reading through all the mails, I realized that I can reformulate my
> 'mental model' in a slightly different manner. Ie, in Mark's 'complete'
> chaining rules there is _no_ difference (except for syntax on whether
> they use URI or protected CURIE) between @about, @resource, @href, and
> @src.

That's correct. Note that this is a _consequence_ of applying chaining
rules consistently, rather than an initial design goal. I.e., it stems
from the fact that a resource could be the subject of a statement, or
the object of a statement, or both a subject and object at the same
time.


> The only issue at hand is *their relative priority*.  All these
> attributes can set object and/or subject. If there is only one, it sets
> the subject; if there are two of them, the higher priority sets the
> subject, next in line sets the object; if there are three of them then,
> well, the third looses out:-).

Ah...not quite. I would say that the only issue is what happens when
you put a @rel or @rev on the same element as one of these 'generic'
attributes. Until you do that, they will all exhibit the
object/subject features you mention. But once they come into contact
with @rel, they have to go to one side or the other -- they have to
either be a subject in relation to that @rel, or an object.

This doesn't mean that they lose their generic object/subject-ness --
it just means that if they go to the left of @rel and become its
subject, they will simultaneously be an object for any statements
'above'. And if they go to the right of @rel and become its object,
they will simultaneously be a subject for any statements 'below'.

Pictorially, I see it like this. The 'generic' layout is like this,
with all of the middle resources being object/subjects, and of course
the first resource being a subject, and the last an object:

  resource
      |
      |
  predicate
      |
      |
  resource
      |
      |
  predicate
      |
      |
  resource

This chain can go on forever, but if you put a predicate on the same
line as the subject and object it connects, then obviously one
resource has to go to the left (subject), and one has to go to the
right (object):

  resource
      |
      |
  predicate
      |
      |
  resource--predicate--resource
                           |
                           |
                       predicate
                           |
                           |
                       resource

So the priority question applies only to the situations when there is
more than one attribute that could play a role. You could represent
that pictorially, like this:

 |        |      |           |
 | @about |      | @resource |
 |        |      |           |
 | @src   | @rel | @href     |
 |        |      |           |
 | bnode  |      | bnode     |
 |        |      |           |

This shows that all attributes must go to the right or left of @rel,
and also illustrates their pecking order within their respective
positions.

(I'm putting @src on the left only to fill the list up and show
priorities. I realise that the decision has not yet been made on where
it should go.)


> (And then there are rules on which value
> goes 'down' the chain.)

Actually there is only one rule, the object/subject sets the context
for any children. So, if there is no @rel then we're dealing with one
of our generic object/subject attributes, so that will provide the
object for any parent statements, and the subject for any children.

And if @rel is present, the resource to the left of @rel becomes a
subject/object, whilst the resource to the right remains an
object/subject. Then all we do is to follow the priority rules in the
box above to work out what the value of the right-hand side of @rel is
(the object for @rel), and then that is the subject for any nested
statements.


> In fact, the reasons we have more than one of
> these animals is because:
>
> - we need at least two to set an object and a subject in the same element

Yes.


> - we inherit some of these from XHTML, namely @href and @src, and we
> decided that we have to adopt them to RDFa, too

Yes, exactly. :)


> Otherwise, these guys are absolutely identical. First of all, is that a
> correct model?

Do you mean 'have I (Ivan) understood your (Mark's) model correctly?'
If so, I'd say that you definitely have, except for the point about
prioritisation; I'm saying that in the presence of @rel, the
attributes have to take on the subject-role to the left, or the
object-role to the right, but they will always go the same way in
relation to @rel, irrespective of what other attributes are on the
element.

But if you mean 'is such a model wise?' then obviously that's a
rhetorical question, so I can't answer it. :)


> That means that, for example
>
> <div resource="#a" rel="a:b" href="#c"/>
>
> yields
>
> <#a> a:b <#c>.

No. In this case, applying the grid above, you would get:

  _:a a:b <#a> .

I.e., both @resource and @href shift to the right in the presence of
@rel, and then according to our list, @resource takes priority.


> (and <#a> is used to 'plug' possible hanging rels 'upwards' and <#c> is
> the subject for possible, say, @property attributes 'downwards'.) Right?

Right concept, but the bnode would 'plug' upwards (it becomes a
subject/object) and <#a> sets the subject 'downwards' (it becomes an
object/subject).


> I also agree with Ben that, if this is the way we go, the only logical
> conclusion is that @instanceof applies to whatever the current subject
> is, regardless of whether it stems from an @about or a @resource or a
> @href or a @src value. After all, these are all, essentially, identical
> attributes!

Right. Good. Although there is a separate thread for that debate, so
it might be worth mentioning that there, just in case it gets lost.


> The _only_ extra rule on @instanceof we do have (remember
> the discussion before Xmas) is that if there is nothing else around in
> an element, @instanceof creates an extra blank node for a subject.

I thought that was resolved...do you think it's not? Or are you just
pointing out that we mustn't forget to include it?

According to the grid, whether @instanceof gets to create a bnode or
not depends on the presence or not of one of the attributes that is
above it in the list (@about and @src).


> I must admit that this model is coherent. However, I am still concerned
> by the examples of Ben. I can attribute them to the fact that @href (and
> @src, but that is less of a problem, probably) plays a dual role. Namely
> we try to adjust its behaviour to RDFa but it also has a totally
> different role for XHTML. Ben's examples reflect the clash on these two
> roles.

Yes, I agree. I'd be really pleased if we were able to accept that
although some of the formulations we have been playing with 'look'
quirky, for consistency's sake we should support them (@resource and
@href as subject, @instanceof applying to @resource and @href, and so
on). That would leave the problem you refer to as something in its own
right, and as you correctly say it relates to the tension we will
inevitably have between attributes that were intended for one purpose,
being used for another.

We can then debate that one issue and give it the attention it deserves.


> Manu claim that this is not a problem; Ben claims it is and, I
> must admit, I am not convinced by Manu on that. As before, my primary
> discomfort is (and has always been) with the sudden appearance of
> spurious triples:-(

I think the argument being put forward is that an author is not going
to get "spurious" triples, if they know the rules. My suggestion would
therefore be that we don't bother too much with that argument. (For
example, do I get "spurious" triples if I use @rel="next"? Only if I
didn't know that its use generated a triple.)

That doesn't mean that there is no argument, and I think a stronger
one is one that you raised before, that it is difficult to use <a>
merely to represent a clickable link, with no concern as to how it
effects RDFa. I'm not saying I have a solution, but I think that is
the real core of the problem.


> One more thing. I also realized that the attribute names are very badly
> chosen if we take this model:-( For somebody coming from the RDF/XML
> world, @about and @resource have a clear meaning.

Which of course is no coincidence. :) In my very early drafts I
actually had this:

  <div rdf:about="s">
    ...
  </div>


> And that meaning is
> _not_, as far as I can see, compatible with Mark's model (and it is more
> compatible with Ben's more restrictive model).

I think it is compatible, if you bear in mind that all attributes have
to go left or right when placed into contact with a @rel. So up until
that point, they might as well be called @blob and @blah. But the
moment @rel appears on the same element, each attribute must go left
or right, and then its name actually gives quite a clear indication of
what it does.


> Indeed, Also, because the
> (English) names are very different, one easily tries to assign them very
> different behaviour whereas, in fact, they are not different. Not sure
> we can do anything about it; finding new attribute names is like finding
> a good abbreviation for a project, it needs a white table, a good meal
> and some glasses of beer:-).

:) Very true.


> But it may be worth remembering that and
> maybe making a note in the primers and tutorials...

Yes. Definitely.


> I am not sure it helped you guys, but it helped me...

I think it was useful...thanks again.

Regards,

Mark

-- 
  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 14:31:20 UTC