Re: Does @instanceof apply to @href?

Hi Manu,

On 22/01/2008, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> Ben Adida wrote:
> > I note that you were recently quite unhappy with the possibility that
> > @instanceof would apply to @href/@resource (which is reminiscent of my
> > proposal). Have you changed your mind?
>
> I'm still unhappy about @instanceof applying to @href/@resource, but see
> it as a possible solution to your, and possibly Mark's, "logical
> consistency problem". If we have @instanceof apply to @href/@resource,
> we create a new "complicated for XHTML developers" problem.

I'm not trying to *add* something here; I drew attention before Xmas
to the fact that with generic chaining rules (i.e., the rules I'd
proposed) there were certain formulations that looked a bit odd, but
that were legal. I asked whether there was any good reason to
*prevent* them, and have been trying to point out that preventing some
of these formulations from generating triples actually makes things
inconsistent.

So let's say that we agree that we really want to _inhibit_ the effect
of @instanceof on @resource and @href. I don't at all accept that
there is a "complicated for XHTML developers" problem -- people don't
need to use these formulations if they don't want to, and anyone
writing a 'beginners guide to RDFa' that uses these formulations in
the first paragraph deserves severe punishment :) -- but let's put
aside why we might prevent @instanceof applying to @resource and
@href, and focus on how it might be achieved.

Well the first and easiest way is to say that @resource and @href
don't act like subjects for nested statements...they don't act like
subjects at all. I think we've all agreed that being able to set the
context for nested statements is desirable, so we'll rule that option
out.

The second way is to say that @resource/@href only set the subject for
contained triples, but not for any predicates on the same element.
That means that whilst this generates what the author wants:

<div resource="#ben">
   <span property="foaf:name">Ben</span>
   <span rel="foaf:knows" resource="#mark" />
 </div>

the @property/@content pair should be ignored here:

 <div resource="#ben" property="foaf:name" content="Ben">
   <span rel="foaf:knows" resource="#mark" />
 </div>

That seems overkill -- unnecessary and confusing -- since why would we
_not_ allow it? It's a fairly basic optimisation to move a predicate
from the nested position to the element itself, and it looks odd to
allow it with @about, but not with @resource or @href.

So the third option would be to say that @resource and @href can set
the subject for contained statements, _and_ can even set the subject
for predicates on the same element, but they don't set the subject for
@instanceof. That's the route you seem to be proposing:

> [...]

> RDFa Syntax Document, Section 5.3.2.4:
> ----------------------------------------------------------------------
> CURRENT TEXT:
> The [current element identifier] is set to the value of @about, if
> present, or the value of @resource, if present, or the value of @href,
> if present, or the value of @src, if present, or a [blank node].
>
> PROPOSED TEXT:
> The [current element identifier] is set to the value of @about, if
> present, or the value of @src, if present, or a [blank node].
> ----------------------------------------------------------------------

But now that means that @instanceof will generate a bnode, giving us
two possible subjects on the element; if we accept my reasoning above,
that @resource should set the subject for @property, then that gives
you one subject, and if we accept your reasoning, that @instanceof
defines a bnode, then that gives us a second subject.

Which should @property bind itself to? Which should be used for any
nested statements?

The only way to get what you want is to simply ignore the @instanceof
attribute altogether when @resource or @href is present, but when
there is no @rel. That's quite a rule!

Although it's true that an attribute can have no effect in our current
processing rules, the only time that happens is if another attribute
that plays the same role has a higher priority (@src, @resource,
@href, for example). But we don't have any rules that say an attribute
has absolutely *no* effect on the triples generated if there is some
other combination of attributes present. I'm certainly not sure how
I'd write that, but either way, hopefully you can see that to say that
@instanceof does not apply to @resource would take more than what you
have written above.

To be 100% clear, what you have above says that @instanceof should not
take its subject from @resource or @href, but that doesn't prevent it
from generating a bnode. You could say that this is what you wanted
anyway, which means that we'd need to rewind my previous logic, and
say that @property does not attach itself to @resource or @href. But
that causes problems when we try to merge this:

  <div instanceof="foaf:Person" property="foaf:name">
    Manu
  </div>

which gives:

  _:a rdf:type foaf:Person .
  _:a foaf:name "Manu" .

with this:

  <div resource="#manu">
    <div rel="foaf:knows" resource="#ben" />
  </div>

which gives:

  <#manu> foaf:knows <#ben> .

Although we get this:

  <div resource="#manu"
   instanceof="foaf:Person" property="foaf:name" content="Manu"
  >
    <div rel="foaf:knows" resource="#ben" />
  </div>

this mark-up no longer yields the merge of the two graphs; I would expect this:

  <#manu> rdf:type foaf:Person .
  <#manu> foaf:name "Manu" .
  <#manu> foaf:knows <#ben> .

since all that has changed is that we have given a name to the unnamed subject.

But to follow through the proposals for @instanceof not operating on
@resource, if we agreed to 'ignore' @resource when @instanceof is
present (and there is no @rel), then we get the bnode version:

  _:a rdf:type foaf:Person .
  _:a foaf:name "Manu" .
  _:a foaf:knows <#ben> .

But 'ignoring' @instanceof when @resource is present (and there is no
@rel), is no better; we get the named version, but we lose the type:

  <#manu> foaf:name "Manu" .
  <#manu> foaf:knows <#ben> .

I believe that either route is confusing for authors ("why are some
attributes ignored when used in certain combinations?"), and it makes
the processing rules more difficult to write. And it's quite difficult
to see what exactly the gain is, when it's quite straightforward to
process *all* of the attributes in a consistent way, by saying that
@resource and @href set the subject for both @property and
@instanceof.

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 12:06:18 UTC