W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

Re: Re 2: PROPOSAL to close ISSUE-37: Clarifying bnode explanation

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Wed, 20 Oct 2010 19:29:13 +0100
Message-ID: <AANLkTin41iEB2o8K89uDOFX7qd_r-k3hk5iCZNBHTiBK@mail.gmail.com>
To: Toby Inkster <tai@g5n.co.uk>
Cc: Ivan Herman <ivan@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Hi Toby,

I think you're losing track of the discussion here.

The only reason I started talking about 'on the way in' and 'on the
way out' was to stress the distinction between triples that are the
result of parsing, and a serialisation of triples that already exist.

This is an important distinction, because the issue everyone seems to
be enjoying talking about only arises when you *round-trip* the
triples; i.e., you take some serialisation, you parse it, you get some
triples, and then you serialise those triples back out again.

Only then can you talk about different blank node identifiers existing
in the two different serialisations.

But our examples aren't doing that!

Our examples show one serialisation (RDFa) followed by another
serialisation (Turtle) in an attempt to give an impression of which
triples would be generated.

It's a very approximate way of explaining what happens when parsing
the first serialisation (RDFa), since all we've done is swap one
serialisation for another. But it's the best we can do, since there's
no syntax for RDF (it's abstract).

However, nowhere do we say that in between the two serialisations
(RDFa and Turtle) the data has been stored and re-serialised. And
since nothing has happened in between those two serialisations then it
would be *wrong* to have a mismatch in the blank node identifiers that
are used in those two serialisations.

Regards,

Mark


On Wed, Oct 20, 2010 at 1:52 PM, Toby Inkster <tai@g5n.co.uk> wrote:
> On Wed, 20 Oct 2010 09:35:22 +0100
> Mark Birbeck <mark.birbeck@webbackplane.com> wrote:
>
>> The bnode identifiers need to be the same *on the way in*. Your
>> example is fine when it comes to querying the triples *on the way
>> out*, but that isn't what the examples are trying to show.
>
> I don't understand this whole "way in"/"way out" distinction. It
> assumes a workflow of a parser putting the triples into a store, and
> then the triples being retrieved from the store by some process. There
> may not be a store at all.
>
> Consider this example using my parser which simply prints triples to
> STDOUT in N-Triples format as they occur. No stores.
>
> ############################################################
> use RDF::RDFa::Parser;
>
> my $xml = <<'XML';
> <p>
>        <span about="[_:foo]"
>              rev="next Index CONTENTS"
>              resource="[_:bar]"></span>
> </p>
> XML
>
> # new($markup, $baseuri, Config->new($hostlang, $rdfaversion))
> my $p = RDF::RDFa::Parser->new($xml, "http://example.com/",
>        RDF::RDFa::Parser::Config->new('html4', '1.1'));
> $p->set_callbacks({
>        pretriple_resource => 'print',
>        pretriple_literal  => 'print',
>        });
> $p->consume;
>
> 1;
> ############################################################
>
> Blank node identifiers will be random-looking ones not bearing any
> relationship to the strings "foo" and "bar" (they're generated using
> UUID numbers).
>
> These random-looking blank node identifiers are generated at the time
> of processing @about and @resource for CURIEs - before they're
> combined with the predicates to form triples - so at no point (not even
> a transitional stage in memory) does a triple exist which has blank node
> identifier "_:foo" or "_:bar".
>
> As far as I'm concerned, that's a conformant implementation. But there
> is no "way in" stage that has access to the triples in the state you
> describe - the triples simply never exist in that state.
>
> --
> Toby A Inkster
> <mailto:mail@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
>
Received on Wednesday, 20 October 2010 18:30:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC