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

Re: Summary of @href/@resource completing triples issue (v2.0)

From: Mark Birbeck <mark.birbeck@formsPlayer.com>
Date: Wed, 9 Jan 2008 20:52:25 +0000
Message-ID: <a707f8300801091252g1202349duf99832573be22961@mail.gmail.com>
To: "Manu Sporny" <msporny@digitalbazaar.com>
Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi Manu,

You have a knack for this! :)

Yes, that is a good summary of the 'incomplete triple' aspect of the problem.

Note though that there are not "two models" under discussion here. :)
There is the model that I proposed, and then there are a set of
'exceptions' to my model that are being discussed. So the first and
third examples work in 'both models' because there is actually only
one model. And the second example generates no triples in Ben and
Ivan's approach because they explicitly want to inhibit @resource and
@href from 'completing triples' in my model.

So no-one is proposing an alternate model to mine, they are just
suggesting that some of the formulations that my model enables should
be prescribed.

(More on this below.)

The core of the issue is therefore this; although we now agree that
these two formulations are equivalent in terms of the triples
generated:

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

  <div resource="A">
    <div rel="p1" resource="B" />
  </div>

the argument is that the congruence of @about and @resource should
*not* extend to the completion of any incomplete triples. In other
words, the following two are NOT equivalent in terms of triples
generated:

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

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

As I've said before this breaks our cut-and-paste model, because a
sub-graph that works standalone is now no longer able to be brought
into relation with another graph, without modifying the layout, which
in this case would involve moving the @rel from the top line to the
second (in the second example):

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

But the key reason I raised this whole thing initially was because I
wanted to define the processing rules such that all we needed to do
was (a) establish 'a subject', and then (b) use it in further
processing, such as with @instanceof, or for completing 'incomplete
triples'.

Essentially I wanted to separate the rules for determining what the
subject was, from what you actually did with the subject, once
established. This definitely makes it easier to write a parser, but I
thought it might also make things easier to learn from a language
standpoint.

However, although we agree that @resource and @href can set 'the
subject', if we decide to say that they can't complete triples then we
have to prevent them from behaving like the 'generic subject' that I
wanted to establish. And that means having rules for @href and
@resource that are distinct from the rules for @about and the bnode
generated by @instanceof.

That's not the end of the world, of course. :) If people really think
that @href and @resource completing triples is something that must be
avoided, then adding extra processing rules is neither here nor there.
I'm just trying to give some context.

Regards,

Mark

On 09/01/2008, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> Sorry folks, Ben's right, there were several bugs in the last summary...
> I'm repeating this because all three of these should turn into test
> cases and we need to make sure that they're correct representations of
> the issue:
>
> This works for both models:
>
> -----------------------------------------------------------------
> <div href="#me">
>    <span rel="foaf:knows" href="#ivan">
>    <span rel="foaf:knows" href="#shane">
> </div>
> --------
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -----------------------------------------------------------------
>
> and this is where the two models differ (note that @rel was moved up to
> the containing element and the href is changed to @about):
>
> -----------------------------------------------------------------
> <div about="#me" rel="foaf:knows">
>    <span href="#ivan">
>    <span resource="#shane">
> </div>
> -------- Approach A triples (Mark)
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -------- Approach B triples (Ben)
> NO TRIPLES GENERATED
> -----------------------------------------------------------------
>
> If you replace each @href/@resource with @about in the second example,
> the two different approaches generate the same triples:
>
> -----------------------------------------------------------------
> <div about="#me" rel="foaf:knows">
>    <span about="#ivan">
>    <span about="#shane">
> </div>
> -------- Approach A triples (Mark)
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -------- Approach B triples (Ben)
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -----------------------------------------------------------------
>
> -- manu
>
> --
> Manu Sporny
> President/CEO - Digital Bazaar, Inc.
> blog: Intro to the Semantic Web in 6 minutes (video)
> http://blog.digitalbazaar.com/2007/12/26/semantic-web-intro
>
>
>
>


-- 
  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 Wednesday, 9 January 2008 20:52:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 January 2008 20:52:38 GMT