Re: status of patch

* Sandro Hawke <sandro@w3.org> [2014-04-17 07:08-0400]
> On 04/17/2014 05:58 AM, Eric Prud'hommeaux wrote:
> >* Sandro Hawke <sandro@w3.org> [2014-04-16 23:48-0400]
> >>The basic resources we produced before we set PATCH aside:
> >>
> >>    https://www.w3.org/2012/ldp/wiki/LDP_PATCH_Proposals
> >>    https://www.w3.org/2001/sw/wiki/PatchRequirements
> >>
> >>
> >>Why I gave up:
> >>
> >>    For my applications, I can't set aside the first two "general
> >>    requirements",  Universality (patching any graph to any graph) and
> >>    Tractability.  But I saw no way to meet them while still being
> >>    standards compliant.
> >>
> >>Why I said we could solve this in half an hour:
> >>
> >>    Because I know how to meet them now.   Use "Virtual Skolemization",
> >>    where graphs with bnodes *appear* to be Skolemized when accessed via
> >>    the patch-specific media type(s).    I updated TurtlePatch to use
> >>    this technique (although it's not explained perfectly).
> >>
> >>Talking to Alexandre, today, it became clear his requirements are
> >>different.  He doesn't care about Universality, so he has lots of
> >>other options.   And given that, he finds the Skolemization thing
> >>too painful/ugly.  And it is, if you don't happen to need it.
> >The Skolemization approach offers great power at great expense.
> 
> Maybe we can clarify what that cost will be? In my deployment
> scenario servers already have a unique handle for each blank node,
> since all the data is in a database, so the cost is negligible. I
> understand some people just keep the data in an RDF serialization in
> the filesystem. In that case, yes, it's more expensive because you'd
> actually need to store the Skolemized version on disk instead, and
> that's going to expand your representation, since you can't use
> constructs like ( ) and [ ] in Turtle. Still, that seems like a
> pretty minor expense.
> Is there something I'm missing?

If someone publishes data with a BNode, it's usually because they
don't intend to honor a long-term identifier for that node. Otherwise,
they just give it a URL. (Of course, a system which make everything a
URL but doesn't honor old URLs should advertise that by using BNodes
rather than contributing to the brokenness of the Web.)  I think we're
only talking about the cases where someone specifically didn't want to
wire up a mapping between database nodes and RDF nodes.

Within the W3C infrastructure, there are some tables where the primary
keys make it into URIs, e.g. user numbers, and others where, every
time a calculation occurs, nodes are destroyed and created with new
numbers. Tying these to something like Oracle rowid would require some
architectural changes to provide a repeatable sequence, respectful of
deletions. I imagine that analogous systems have emerged in the RDB
world but never made it into the SQL spec. SQL updates are just as
hard (complex) as SPARQL updates, though the indexes are potentially
less crowded in practice.


> >  The
> >SPARQL approach offers great power at potentially great inefficiency.
> >My bet is that the SPARQL with constant predicates will work for 99%
> >of our use cases.
> >
> >I don't know if SPARQL_patch (a strict sublanguage of SPARQL) is still
> >on the table, but here's a yacker grammar for it:
> ><http://www.w3.org/2005/01/yacker/uploads/SPARQL_patch/bnf>.
> >
> >It validates <http://w3.org/brief/MzYz> this example patch:
> >
> >eric@mouni:~/checkouts/SWObjects$ ./bin/sparql -d 'data:text/turtle,
> >   PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> >   <alice> foaf:mbox <mailto:alice@example.org> .
> >   <bob> foaf:mbox <mailto:bob@example.org> .
> >   <eve> foaf:mbox <mailto:eve@example.org> .
> >   <sue> foaf:mbox <mailto:sue@example.org> .
> >   <bob> foaf:knows <alice> .
> >' -e'
> >   PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> >   DELETE { ?bob foaf:knows ?alice }
> >   INSERT { ?bob foaf:knows ?eve ; foaf:trusts ?eve }
> >    WHERE {
> >       ?bob foaf:knows ?alice .
> >       ?alice foaf:mbox <mailto:alice@example.org> .
> >       ?eve foaf:mbox <mailto:eve@example.org>
> >   }
> >' -l turtle
> ><alice> <http://xmlns.com/foaf/0.1/mbox> <mailto:alice@example.org> .
> ><bob> <http://xmlns.com/foaf/0.1/mbox> <mailto:bob@example.org> .
> ><eve> <http://xmlns.com/foaf/0.1/mbox> <mailto:eve@example.org> .
> ><sue> <http://xmlns.com/foaf/0.1/mbox> <mailto:sue@example.org> .
> ><bob> <http://xmlns.com/foaf/0.1/knows> <eve> .
> ><bob> <http://xmlns.com/foaf/0.1/trusts> <eve> .
> >
> >
> >(Uh oh, looks like eve is up to her old tricks again.)
> >
> >I picked this example because it's been the principle argument for
> >skolemization (aka "told BNodes" or "bnodeRef"
> ><http://www.w3.org/2001/sw/DataAccess/issues#bnodeRef>). One can
> >minimize the search space by starting with the triples with the most
> >constants (i.e. foaf:mbox), but the search space can indeed get large
> >if you have a long string of ?A knows ?B. IMO, that's a small cost
> >compared to that of deploying solemnization.
> >
> >Note that this update also qualifies as a "nailed" patch in that
> >replacing the DELETE… INSERT… with SELECT * yields:
> >┌─────────┬───────┬───────┐
> >│ ?alice  │ ?bob  │ ?eve  │
> >│ <alice> │ <bob> │ <eve> │
> >└─────────┴───────┴───────┘
> 
> I'm willing to grant that this is fine 99% of the time, but for my
> applications that's not good enough. I need universality and
> tractability every time. (I need graph synchronization between
> arbitrary graphs; the graphs are constructed by applications that
> don't even know they're using RDF, and will not look kindly to some
> operations unexpectedly not working.)

Does it behove society to make that specialized requirement a commodity
product, and to make it *the* RDF patch?


> -- Sandro
> >
> >
> >>         -- Sandro
> >>
> >>
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 17 April 2014 12:26:36 UTC