Re: status of patch

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?

>   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.)

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

Received on Thursday, 17 April 2014 11:08:40 UTC