Re: Joseki problems

Seaborne, Andy wrote:

>Thanks for all these comments.  And thanks for checking in the code into
>SIMILE CVS.  I'll grab it when I'm in work next.
>
>What is your experience with the Perl RDF modules?  I haven't done any RDF
>work in perl yet although one of my query collaborators is the author of
>RDFStore.  I have used Python/RDFlib, Sesame (as well as Jena!).
>
>Is the code of high quality and well thought out?  Does it have opinions
>about how the application should process RDF or is it Jena-like (tries to be
>a direct API to the RDf graph).  Is it uptodate with the recommendations?
>If there are different modules in CPAN, which one(s) are best?
>
>More inline below.
>
>	Andy
>
>  
>
>>----Original Message----
>>From: Kevin Smathers <mailto:kevin.smathers@hp.com>
>>Date: 17 November 2003 23:20
>>
>>Seaborne, Andy wrote:
>>
>>    
>>
>>>      
>>>
>>>>3. AddToModel is implemented as an HTTP POST, with the operation
>>>>immediately after the '?' following the model name.  Ie:
>>>>http://foo:9090/model?add, and the document containing statements
>>>>to be added in the POST attachment.
>>>>
>>>>
>>>>        
>>>>
>>>And "remove".
>>>
>>>
>>>      
>>>
>>Okay, but there should also be a form of remove that takes a query as
>>its argument.
>>    
>>
>
>Yes - although I have no solution for the consequence of this on multiple
>accessed models.   Delete-by-query presumes the caller has a definite idea
>of what the data looks like.  If some other app is updating the model, it
>also has an idea of the state of the model.  Even if changes are done
>safely, in a distributed system there is a real problem of doing some
>exploration, then issuing a query-by-delete while someone else is chnaging
>the model.  The query may have undesirable effects.  
>

I would rather put it the other way around.  Delete by query is for a 
situation where the caller has no definite idea what is in the 
repository, but needs to delete what is there, not what he thinks is 
there.  In a shared access situation, delete by query is one of several 
possible atomic read and write operations.  The result of the operation 
should probably be to send the caller the list of statements that were 
deleted by the query.

>
>Maybe an update operation count needs to be added and if the model copy of
>this count if different, a remove-by-query is rejected.  There needs to be
>some consistency encouragement.
>
I can't see any use for this, but then my imagination is limited.  If 
you know the contents that you are trying to delete, then explicit 
delete is sufficient.

>
>What I am trying for in Joseki is not a complete application server for
>closely coupled (essentially one design authority) applications, but a
>loose, web-scale federation. This is also why I have concentrated on the
>publish side.
>
>The update/change side is rather far behind and I am looking for a paradigm
>for how change and update happens on the semantic web.  Once the picture is
>clear, choosing operations is a matter of work - the other way round doesn't
>work for me.
>
Well, to start with basic operands should be idempotent, but that is 
trivial with RDF; so add, remove, etc. all work fine.   The second 
problem is updating the metastore when two people might be 
simultaneously accessing the data.  For this to work reliably, the 
server needs read and write instructions similar to the 'cvs' patch 
command.  Remove this data, but only if it is present (and optionally 
has a specified value); add this data, but only if it is missing, and 
swap this data (optionally with specified value) for this other data.

>
>I have thought about looking at WebDAV as a style of approach but haven't
>done anything about it.  As currently, there is the "semantic web for HP"
>work, query discussions as well as the support/development load from Jena, I
>have had to focus Joseki work on the publishing side.
>
>BTW: Have you looked at URIQA?  It uses modifications to HTTP to access
>metadata.  I don't understand its update model or where RDF is located - the
>PUT examples confuse me.
>  
>
No, sorry.

>  
>
>>>      
>>>
>>>>4. Ping is implemented using an HTTP POST with any empty document
>>>>attachment, and the word 'ping' in the command location.  Ie:
>>>>http://foo:9090/model?ping. 
>>>>
>>>>I haven't yet been able to track down references for PutModel or
>>>>UpdateModel, so I don't know how these work yet.
>>>>
>>>>
>>>>        
>>>>
>>>There is no use of HTTP PUT or of composite update (it would be done
>>>with a multi-part MIME message for each of the two graphs).
>>>
>>>
>>>
>>>      
>>>
>>You seem to be implying that Update is just an atomic remove plus add,
>>is that right?
>>    
>>
>
>Yes it is for an RDF graph.  Chnages are affected by removing triples then
>adding the replacement.
>
>  
>
>>I'd like to see something with semantics more like if {s,p}->o1 then
>>replace it with {s,p}->o2.
>>    
>>
>
>Possibly useful but I think it is getting into the domain of application
>"protocol" on top of base RDF.  Is there a nature fixed set of operations?,
>especially as the protocol is graph centric, not statement centric.
>
>  
>
>> Also, addIfNotExists with the same
>>semantics.  I'm not sure how to express both existence requirements
>>and 
>>non-existence requirements with a single graph, but using two queries
>>is 
>>pretty easy.
>>    
>>
>
>addIfNotExists is not needed - just add.  An RDF graph is a set of
>statements so is idempotent.  Or did you mean "add S1 is S2 does not exist"
>  
>
The return value is different, and the distinction helps applications to 
tell if:
a) they are potentially in conflict
b) they have responsibility for the data they just created (and thus 
need to clean up after themselves)

I might have instead asked for ref-counts on add and remove, but using 
addIfNotExists as a Mutex, one can then implement semaphores which in 
turn allows the applications to negotiate some sort of reference 
counting mechanism among themselves via the Joseki store.

Actually when we were defining Genesis, this was a heavily debated 
subject; should clients perceive the metastore as a repository of 
statements, or of statings.  In our case we concluded that the abstract 
statement has no place in real program development; that developers
will want to work with statings -- things that they own and control, 
that can be protected, or shared, rather than things that exist 
abstractly regardless of who created the stating that caused the statement.

>Maybe the building block is an operation of the form:
>
>:: Preconditions (or maybe just "pattern")
>:: Action
>
>possible that is a single HTTP operation or possible it is finer grained
>than that and an HTTP operation is a batch of them (not that HTTP 1.1 adds
>too much overhead ir the connection remains open).
>
>  
>
>>>      
>>>
>>>>Cheers,
>>>>-kls
>>>>        
>>>>
>
>One possibility you might like to consider is to note that the RDF graph
>published by Joseki can be in a database and that database can be updated
>(transactionally) while the server is running from a separate application.
>Joseki performs operations atomically (transactions if available, MRSW
>locking if not).
>
>The prime role of a Joseki server at the moment is the publishing (=> don't
>know who the info consumer is).  Update and change is more complicated than
>publishing and where there are several distibuted client there needs to be
>"co-ordination" (examples: by design, just one client takes ownership of
>part of the graph hence no clashes happen; the operations are safe, or there
>is a transational relationship, or there is a full coordination protocol).
>
>	Andy
>  
>
I think this conversation is getting too interesting to keep to 
ourselves, so I've CC'd the main list, which hopefully be any cause for 
upset.  I'd especially like other people to be able to give their 
opinions on the interaction of multiple clients through a Joseki store.

Cheers,
-kls

-- 
========================================================
   Kevin Smathers                kevin.smathers@hp.com    
   Hewlett-Packard               kevin@ank.com            
   Palo Alto Research Lab                                 
   1501 Page Mill Rd.            650-857-4477 work        
   M/S 1135                      650-852-8186 fax         
   Palo Alto, CA 94304           510-247-1031 home        
========================================================
use "Standard::Disclaimer";
carp("This message was printed on 100% recycled bits.");

Received on Tuesday, 18 November 2003 13:52:38 UTC