Re: Rethinking @src in the context of chaining rules

Mark Birbeck wrote:
> There were no other arguments. I was pointing out that it is not true
> to say that the definition of the attributes was "static", which was
> the word you used. Even in that simple example you can see that @about
> is both a subject and an object, even without a second sub-graph.

Right, and I think we're talking past each other here when I say "@about
sets the subject" and you say "but it's also an object!", so let's try
to move past this language and just talk about what triples are generated.

> A graph is made up of complete triples though. So a sub-graph can't be
> made up of a vertex (e.g., just a subject)...it doesn't mean anything.

Actually, I'm pretty sure a single vertex with no edges is a graph,
theoretically speaking. It's not very useful, but it's still a graph.

> Anyway, a few emails ago you seemed to suggest that the example above
> shouldn't generate any triples,

Let's move on from this because I did *not* suggest this, it was a
misunderstanding. I was only saying it's an edge case and we shouldn't
reason based on edge cases.

>> I also think Ivan's latest point is tremendously important:
>>
>>> how can the user *avoid* the appearance of certain triples?
>> What Ivan is hinting at here is that we may be going down the rabbit's
>> hole we had 2 years ago, where far more triples were being generated
>> than we wanted.
> 
> More than _some_ wanted. :) You are referring to @class, I take it,
> which was hardly a rabbit hole.

Oh no, I'm not referring to @class. I'm referring to the way chaining
was done back when Jeremy wrote the XSLT for us 2 years ago, and we got
hundreds of triples instead of a handful. That situation was the result
of trying to inherit everything.

What you're proposing is effectively that @rel is now "inherited", and
so when you hit @resource, you assume that @about and @rel from above
are still around. That does not blow up the triples as much as the
earlier situation, but it does increase them in possibly unexpected ways.

> But that's like saying if I put an @about on a <div> we no longer have
> the 'normal' functionality of HTML with respect to @rel/@href, since
> the relationship is no longer between the 'current document' and the
> navigable link. That's the way it goes.

No, it's a lot worse than that. Take the following markup:


  <div about="#me" rel="foaf:knows">
    In my work with the
    <a href="http://w3.org">W3C</a>,
    I have come to know:

    <span about="#mark" property="foaf:name">Mark</span>

    and

    <span about="#ivan" property="foaf:name">Ivan</span>.
  </div>


Note the anchor with no @rel, just an @href. I don't want a triple
generated for that right now. But with your rules, anytime I have a
hanging @rel, any clickable link completes it, and there's nothing I can
do to stop it (or, we'd have to make up a "stop the hanging @rel" method.)

There is more I want to say on the examples you sent, but first I want
to hear your reaction on the above issue, since I think Ivan's point
here is super critical.

-Ben

Received on Tuesday, 8 January 2008 17:52:54 UTC