Re: Does @instanceof apply to @href?

Mark Birbeck wrote:
> Now, if we can have this:
> 
>   <div resource="#ben">
>     <span property="foaf:name">Ben</span>
>     <span rel="foaf:knows" resource="#mark" />
>   </div>
> 
> why should we not have this:
> 
>   <div resource="#ben" property="foaf:name" content="Ben">
>     <span rel="foaf:knows" resource="#mark" />
>   </div>

Because it makes things more complicated for resolving @property and it
means that it's really tough to interpret the meaning of any single
attribute without looking at *all* of them.

In my model, @property always applies to @about or an inherited subject
from the parent context, never to @href/@resource on the same element.

Infinite flexibility in markup is not my goal. I prefer to ask "why"
rather than "why not." What do we gain from this? There's no added
expressive power, only more flexible (and thus more complicated) markup.

The nice thing about the portion of your chaining model that we accepted
last month is that it enabled all sorts of beautiful stuff. The idea of
copying a <div> with all of its properties and moving it to the object
of a statement.... genius!

But this additional step you're describing now gives us nothing with
respect to a use case.

In my model, @resource/@href only applies to the children elements, and
that's consistent with @resource/@href not completing hanging @rel.


> We need to ask ourselves if there is any good reason to _prevent_ this
> formulation, and if we were to prevent it, how we would explain the
> reason for this restriction.

There is a good reason, as Ivan has pointed out: this is significantly
more complicated for humans to interpret. I'm still trying to fully
understand it.

We also need to ask ourselves what good reason we have to _enable_ this.
There are different models, Mark, and yours is not the only one.

> @INSTANCEOF
> 
> Just as the use of @property/@content in the way that I have just used
> it flows from the way that @resource and @href can be used as
> subjects, so the use of @instanceof falls out quite straightforwardly,
> too. In the 'generic' processing rules I indicate that @instanceof
> should be applied to the subject, however that is established, and
> since we've accepted (I think), that @resource and @href can set the
> subject for nested triples, then @instanceof should apply to them too.

You're confusing two things here: @resource can become the subject of a
*nested* triple, but not necessarily of properties *on* that triple.

Take for example:

<div instanceof="foaf:Person" rel="foaf:knows" resource="#mark">
    ... stuff about mark ...
</div>

@instanceof applies to a new bnode in this case, and I don't see why it
should apply to @resource when @rel goes away.

In your model where @resource completes hanging @rel, yes, I think
@instanceof would have to apply to @resource, but this is a reason why
it gets really complicated to have this processing rule.

> Note that this whole discussion is very different to the '@href
> completes a hanging @rel' issue;

I strongly disagree. If you look at my model, where @href/@resource does
not complete hanging @rel, then it makes perfect sense to have
@href/@resource only set the subject for *contained* markup, not for
markup on the same element. In my model, @href/@resource is processed
*last* on a given element, after you've figured out what @instanceof and
@property apply to.

-Ben

Received on Tuesday, 22 January 2008 20:42:16 UTC