Re: thoughts on @resource in current RDFa Syntax draft

Hi Ben,

Yes...apologies for missing the call today, but this week turned out
to be the only time we could get away. Still, my family has been given
me an hour in an internet cafe...

:)

On the issue raised, there are two important aspects to it, but the
one I'll focus on here concerns consistency in chaining triples
together. What would you see as being the parsed triples from this:

  <div about="A">
    <div rel="p1" resource="B">
      <div rel="p2" resource="C" />
    </div>
  </div>

I'm assuming we're happy with:

  <A> <p1> <B> .
  <B> <p2> <C> .

What if we split the @rel's and @resource's:

  <div about="A">
    <div rel="p1">
      <div resource="B">
        <div rel="p2">
          <div resource="C" />
        </div>
      </div>
    </div>
  </div>

Any reason why this should not yield the same triples? I'm hoping not.

Now, no-one would bat an eyelid if I rewrote the mark-up like this
(replacing the middle @resource with an @about):

  <div about="A">
    <div rel="p1">
      <div about="B">
        <div rel="p2">
          <div resource="C" />
        </div>
      </div>
    </div>
  </div>

and then I'd be free to add some @instanceof's without any complaints:

  <div about="A" instanceof="t1">
    <div rel="p1">
      <div about="B" instanceof="t2">
        <div rel="p2">
          <div resource="C" />
        </div>
      </div>
    </div>
  </div>

But why can't I add an @instanceof to the last @resource? In
particular, if we go back one step, and restore the @resource in the
middle (in place of the @about), why can I not write this example in
this way:

  <div about="A" instanceof="t1">
    <div rel="p1">
      <div resource="B" instanceof="t2">
        <div rel="p2">
          <div resource="C" />
        </div>
      </div>
    </div>
  </div>

To rephrase the question--which is how I raised it in the first
place--how do we _stop_ someone writing this? (And why?)

Also, given our emphasis on 'cut-and-paste', why shouldn't I be able
to take the inner block of the prior step and use it somewhere else:

  <div resource="B">
    <div rel="p2">
      <div resource="C" />
    </div>
  </div>

And once again, if I can do that, why not this:

  <div resource="B" instanceof="t2">
    <div rel="p2">
      <div resource="C" />
    </div>
  </div>

My key point is that the RDFa attributes should not be bound hard and
fast to 'subject' and 'object', since that is meaningless when talking
of chainingn. Instead their role will depend on their position. But
what I did say in our prior discussion about @instanceof was that it
should always apply to the *subject* on an element.

Note that this is different to the flip-flopping that I was critical
of in the alternate proposal for @instanceof's behaviour; in that
situation @instanceof sometimes applied to a subject and sometimes to
an object, and that caused ambiguities with chaining.

The reason I see this as an important issue is that if you follow my
steps above, at which point would we say that something is not
allowed? Would we say that we can have this:

  <div about="A">
    <div rel="p1">
      <div resource="B">
        <div rel="p2">
          <div resource="C" />
        </div>
      </div>
    </div>
  </div>

but we can't have this:

  <div resource="B">
    <div rel="p2">
      <div resource="C" />
    </div>
  </div>

If so, that defeats our cut-and-paste goals, and is very inconsistent
in terms of rules--and gains us nothing.

Then if we allow @resource to be a subject like @about (which we have
pretty much already done), why do we prevent it from having
@instanceof?

One last point, in terms of complexity for authors I am not at all
proposing that we advertise these formulations; in just the same way
that new students of English or Italian are not introduced to the
subjunctive on day one, so we begin with easy constucts where @about
and @resource work together. But it's important that the syntax
document (aimed at parser authors, don't forget), allows these
'quirky' constructs so as to ensure complete consistency of the
language.

Regards,

Mark



On 02/01/2008, Ben Adida <ben@adida.net> wrote:
>
>
> Hi all,
>
> Hope the new year is starting well for all! Mark, sorry we won't have
> you on this week's call. I've taken a look at the latest RDFa Syntax
> document, and it's coming along *very* well. It's clear, precise, and
> very useful. Mark, Shane, thanks very much for your work on this. Let's
> wrap this up ASAP so we can present this to the WG!
>
> Now, to one of the issues that Mark brought up before the break and that
> is reflected in the current syntax draft [1]:
>
> >   <img src="A" instanceof="B" />
> >
> >   <div about="A" instanceof="B" />
>
> I think everyone is in agreement that the above two examples yield
>
>   A rdf:type B .
>
> >   <div resource="A" instanceof="B" />
> >
> >   <a href="A" instanceof="B">label</a>
>
> This is where we differ. As Manu mentioned in his response, I don't see
> this giving the same triple.
>
> > I really, really hope that is ok. :) If it isn't then it means we are
> > going to have to add lots of special cases to our parsing rules, and
> > that gets quite messy.
>
> I think that's not the case. Reading the syntax draft, I think we could
> take out a chunk and it would fit with Manu's and my interpretation.
> Specifically, all you need to do is take out the line items on @resource
> and @href in the [new subject] resolution.
>
> (Looking it over again, I think that the current write-up doesn't fully
> account for the @resource examples above, since @instanceof is processed
> before @resource and @href. The complete processing rules to support the
> @resource/@instanceof example might end up being even more complicated.)
>
> I think we're dealing with *fewer* special cases and a more intuitive
> model if we say that [new subject] is resolved as follows in the given
> priority order:
>
>  - @about,
>  - @src,
>  - new bnode if @instanceof,
>  - [parent object] if not null (chaining on explicit object)
>  - [parent bnode] if not null (chaining on implicit bnode)
>
>
> I don't see newly enabled use cases if we complicate these rules.
>
>
> -Ben
>
> [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Dec/0125
>
>
>
>


-- 
  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 Thursday, 3 January 2008 11:03:49 UTC