W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > January 2008

Re: Does @instanceof apply to @href?

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 22 Jan 2008 11:01:37 +0000
Message-ID: <a707f8300801220301g1d10a4c2o240918de831f6dbf@mail.gmail.com>
To: "Ben Adida" <ben@adida.net>
Cc: "Manu Sporny" <msporny@digitalbazaar.com>, RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi Ben,

> [...]

> I need you to address the use case I'm having trouble
> with in my other email:
>
>   <div about="#me" rel="foaf:knows">
>      <div href="#mark" instanceof="foaf:Person" property="foaf:name">
>         Mark
>      </div>
>   </div>
>
> You're saying that this yields:
>
>   <#me> foaf:knows <#mark> .
>
> But now, what about @instanceof and @property? Do they also apply to
> <#mark>?
>
>   <#mark> rdf:type foaf:Person .
>   <#mark> foaf:name "Mark" .
>
> Am I correct in understanding that, in these chaining cases in your
> model, @property can have @href as its subject?

That's absolutely correct.

Going back one step, I thought that people had accepted that @resource
and @href could play the role of a subject for nested triples:

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

  <div href="#mark">
    <span rel="foaf:knows" href="#manu" />
  </div>

and so on. (I'm having trouble keeping up with what the status quo is,
so if I'm wrong already, stop me. :))

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>

In other words, since we already allow one literal property to move
from a nested position to the containing element if the subject had
been set with @about, why would we prevent the same principle from
applying to @resource and @href?

Don't get me wrong...I'm not asking people to use this formulation, or
to blog about it, or to mention it in primers, or indeed to do
anything at all with this information. For all I care, people can
completely forget about this formulation, just as one could probably
get by in life without ever using the subjunctive. (And if we don't go
on about it, or introduce it carefully, then there is no way that this
formulation could confuse authors.)

But what I have been trying to point out is that this formulation is
*legal* if the rules are made generic, and making things generic makes
things a lot easier to write. But even putting aside the generic
argument, what would it mean to _prevent_ this formulation?


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. Remember, we would be saying that
although it is legal to write this:

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

an author should be careful not to move the @property/@content pair up
one level, because the predicate would now be completely ignored:

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

Hopefully that answers your question, and gives some background to the
rationale -- even if you don't agree with the conclusion.

Now I'd like to look at @instanceof.


@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.

As with @property/@content, if we are to _inhibit_ this behaviour,
things start to get strange. So, although @instanceof applies rdf:type
to the subject in this situation:

  <div about="#mark" instanceof="foaf:Person" property="foaf:name">
    Mark
  </div>

and in this situation (the subject being a bnode):

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

we're saying that it should work in either of the following situations:

  <div resource="#mark" instanceof="foaf:Person" property="foaf:name">
    Mark
  </div>

  <div href="#mark" instanceof="foaf:Person" property="foaf:name">
    Mark
  </div>

So let's ask how we should _prevent_ this formulation from behaving
like the examples above.

Once choice is to use @resource/@href to set the subject for
@property, so as to keep things consistent with the @property/@content
discussion, above. That would mean that the rule is simply to say that
@instanceof is completely ignored in this context.

That seems a waste, since if the author put it there, they most likely
want to set the type of something, so the other alternative is to say
that @resource is ignored, and that @instanceof is processed according
to the rules where there is no subject, i.e., it sets a bnode. This
bnode would then have to be used with @property, and also with any
nested statements, which means that the @resource is confusing.

So either route gives problems 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, if @resource and
@href set the subject for both @property and @instanceof.


Note that this whole discussion is very different to the '@href
completes a hanging @rel' issue; although I would justify the syntax
on the same basis -- it's generic...it's legal...if authors don't see
it how can they get confused...so why prevent it? -- I accept that the
argument that says that we need a way to create XHTML links that do
not generate triples requires a different set of criteria for deciding
its fate, and needs to be dealt with in those terms.

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 11:01:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 January 2008 11:01:54 GMT