Re: Rethinking @src in the context of chaining rules

Hi Ben,

This is the second part of my response to your email, and deals only
with your comments about the way that attributes are used to express
subjects and objects. I've taken this separately from the proposal
that @src should behave like @about, which I have argued against in
the preceding email.

> [snip]
>
> After all, if we write the following markup:
>
>   <span href="#me" rel="foaf:knows" resource="#you" />
>
> should we go down the path of: well @href shifts to subject and
> @resource stays the object, and we get <#me> foaf:knows <#you>?

No. :)


> I sincerely hope the answer is clearly *no*...

It is. :)


> ...and the same conservative
> approach should apply to other attributes: chaining allows us to give
> them *static* roles: @about is a subject, @href is an object, each
> defining its subgraph, and then @rel with chaining can hook portions of
> those graphs together.

I think you've missed some of the key examples I've been trying to
convey -- the roles are far from 'static'. Take this example:

  <div about="A" rel="p">
    <div about="B" />
  </div>

There is obviously no point here in saying that "@about is a subject"
since it is playing both roles. But more than that, it is _not_
playing the role of an object merely by the interconnection of two
sub-graphs as you seem to say, since there is no second sub-graph to
connect.


> It's dangerous to try to make every possible case of markup mean
> something, because that can have serious consequences on the overall
> understandability of the entire spec.

:) Today's newspapers are tomorrow's chip wrappers, as they say. Only
the other day compliments were being handed out on how the spec was
readable, clear, precise, and whatever else; today the same approach
that gave us such a specification has become a threat to civilisation
as we know it.

Ah well...


> Having @src shift from subject to object goes right back to the issue
> you (and everyone else) justifiably complained about when I said
> @instanceof could apply to @about or @resource.

I have referred to this, but I guess it has got lost in the
discussion; the "flip-flopping" that I identified in your proposal
concerned the application of @instanceof sometimes to the subject of a
statement and sometimes to the object of a statement. This meant that
as attributes were added and removed @instanceof switched its
affections from one resource to another.

So, in your model you could use a combination of attributes (@about,
@instanceof, @property and @content) that gave you this:

  <#ben> rdf:type foaf:Person .
  <#ben> foaf:name "Ben" .

but the moment that you added two more attributes to establish that
'Ben knows Mark' (@rel and @resource), the type of Ben would
'disappear', only to magically reappear as the type of Mark:

  <#ben> foaf:name "Ben" .
  <#ben> foaf:knows <#mark> .
  <#mark> rdf:type foaf:Person .

Removing the @rel/@resource combination that specified the
relationship between Ben and Mark would then cause the switching of
affections to be reversed.

In other words, the addition of an extra *statement* caused the
flip-flopping, which is what I was arguing against and I suggested
instead that @instanceof should always apply to the *subject* of a
statement, regardless of how that subject was arrived it; in other
words it never flips (or flops) from one resource to another in the
kind of way just shown.

But that is not the same as having a different syntactical
interpretation on the basis of various combinations of attributes. For
example, we've already agreed that the role of @href in the second
element here:

  <div about="A" rel="p1">
    <a href="B">B</a>
  </div>

is going to be different to its appearance here:

  <div about="A" rel="p1">
    <a rel="p2" href="B">B</a>
  </div>

The first generates:

  A p1 B .

but the second generates:

  A p1 _:a .
  _:a p2 B .

So whether an attribute plays the role of a subject or an object is
*already* determined by the presence of @rel/@rev. But that's the only
rule, which does seem pretty simple.


> > I don't see why we don't retain support for that. The presence of @rel
> > is what turns some of the attributes into objects.
>
> I *really* don't like that. The nice thing about chaining is that it
> made the meaning of attributes *far* more consistent, and did away with
> my @instanceof shiftiness.

They were two separate issues. I proposed making @instanceof always
apply to 'the subject', independently of my proposals on chaining. My
clarifications about chaining were only to do with 'incomplete
triples' (remember that your model of chaining already including
everything from my model, except the 'hanging rel' idea), and the main
motivation for that was to show that the use-cases you were trying to
achieve with your @instanceof rules could be achieved if we added some
extra stuff to chaining.


> Now you want to reintroduce this uncertainty,
> where you need to look at *all* attributes before you figure out the
> meaning of a single one.

Not at all. In fact it is very clear; the presence of _any_ of the
resource-type attributes creates a subject for nested statements,
and/or an object for incomplete parent statements. The only time that
attributes obtain a more specific 'essence' is in the presence of @rel
or @rev, and even then, it's only in relation to each other.


> There's also no use case here, only markup taken from previous rules
> that you're saying should "still work." I disagree with that design
> approach: trying to make every markup approach work is a recipe for
> overly complicated parsing rules.

As I said before, I do actually think the parsing is much simpler.


> Let's go back to a use case and ask: how would one write that? So far,
> this rules does not enable more use cases or cleaner markup, it only
> enables *different* markup at a very high cost to the simplicity and
> understandability of the spec.

That's not true. The use-cases that I've outlined a few times now
relate to consistency when moving items around, so that things that
work in one context have the same behaviour in another. I don't
believe that there are "high costs" to this, or that I am risking the
simplicity of the spec -- quite the contrary.

What I'm finding a little frustrating in this part of the discussion
is that no-one has responded to the very first question I asked, which
I'll paste here again:

--- STARTS ---

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.

--- ENDS ---

Can anyone answer that last question? I.e., explain why this mark-up
should yield exactly *zero* triples? I've never said that we should
*promote* this mark-up, merely that we should support it if we come
across it.

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 Monday, 7 January 2008 22:31:23 UTC