Re: question about RDFPatch headers

[Chris Tomlinson]

Hi Andy,

We appreciate the ideas. If we go with a linking approach we’ll have to add 
some more machinery, which is fine.

Thanks again,
Chris


> On May 17, 2019, at 10:40 AM, Andy Seaborne  wrote:
> 
> Hi Chris,
> 
> If the "meta" part becomes complicated, it might be better to put a link in 
> the header that goes to another file.  There is balance to be struck between 
> arbitrary structures and simple processing.
> 
> It does make some sense to have a multi-valued patch header.
> 
> (all one line with or without separating comma)
> 
> H graph  
>  .
> 
> Having the header as a map makes mixing header entries and reprocessing them 
> work better.  No assumed order creeps in and no confusion about duplicates 
> for things that must be unique (like id). c.f. HTTP headers.
> 
> If you think the meta data is going to get large, then a link to elsewhere 
> may be better for other reasons like using the metadata without needing to 
> access the patch in the log.
> 
>Andy
> 
> On 16/05/2019 18:35, Chris Tomlinson wrote:
>> Hi,
>> We’re building an editing service for our RDF Linked Data Service and are 
>> thinking to use at least some of the features of RDFPatch/RDFDelta.
>> We use named graphs for the various Entities that we model: Works, Persons, 
>> Places, Lineages and so on. We are wanting to include in the patch some 
>> headers indicating the graphs that are being updated in the patch and the 
>> graphs that are created in the patch. We want this information to help the 
>> editing service have easy access to this information w/o analyzing the patch 
>> and doing other work to discover what’s being created and so on.
>> At first we thought of using a couple of keywords like, graph and create:
>> H graph  .
>> H graph  .
>> H create  .
>> H create  .
>> H id … .
>> but org.seaborne.patch.PatchHeader uses a Map so we can only one H graph … 
>> and one H create … in the patch. Two alternatives we’ve considered are to 
>> use a String of comma separated graphIds:
>> H graph "0686c69d-8f89-4496-acb5-744f0157a8db , 
>> 3ee0eca0-6d5f-4b4d-85db-f69ab1167eb1” .
>> H create "b1167eb1-85db-4b4d-6d5f-3ee0eca0f69a , 
>> 0157a8db-acb5-4496-8f89-0686c69d744f” .
>> which is plausible but in some cases the list of graphIds could become quite 
>> long and so this could be an issue down the line with very large strings.
>> A second idea was to add the notion of a preamble to the patch using PS, for 
>> preamble start, and PE, for preamble end, which would separate our 
>> extensions from the defined RDFPatch structure:
>> PS .
>> H graph  .
>> H graph  .
>> H create  .
>> H create  .
>> PE .
>> H id … .
>> TX .
>> …
>> We would then pre-parse the patch payload up to the PE and submit the 
>> remainder to RDFPatch, and so on.
>> A 3rd possibility is to consider some extension to RDFPatch to use a 
>> different signature for the Map in PatchHeader. This seems rather involved.
>> So we’re asking what approaches others might have taken for this sort of 
>> use-case or how best to accommodate this in RDFPatch as is.
>> Thanks very much,
>> Chris

Re: concatenating patches

[Chris Tomlinson]

Hi Andy,

Thanks for the reply. We’ll look more deeply into the rdf-delta repo. I think 
there’s a lot there to at least help inform our design.

Regards,
Chris


> On May 17, 2019, at 8:06 AM, Andy Seaborne  wrote:
> 
> 
> 
> On 16/05/2019 18:48, Chris Tomlinson wrote:
>> Hello,
>> As part of our editing service development, using at least aspects of 
>> RDFPatch, we have a use-case that goes like this:
>> User U_A does some work on a number of resources resulting in patch P_01 and 
>> then stashes the patch on the editing service and requests user U_B to 
>> finish the work item represented by P_01
>> User U_B retrieves P_01 and begins a new patch P_02 that continues on from 
>> P_01 and then
>> User U_B requests the editing service to apply P_01 followed by P_02.
>> This seems like a case where RDF Patch Log 
>>  would be appropriate, 
>> but it isn’t clear from the docs or code exactly how one manages a Log of 
>> patches to be applied in sequence and then requests the sequence to be 
>> applied. I looked about for a PatchLog class but didn’t see such.
>> How would this kind of scenario be handled?
> 
> The id/prev headers provide a way to define a log (a linear sequence of 
> patches with a head and tail).
> 
> There are many ways to use patches
> 
> The patch module on its own does not provide this - that is what modle 
> rdf-delta-client does for the case of an HA dataset.
> 
> DeltaConnection with a SyncPolicy of NONE (not automatic) and call
> 
> DeltaConnection internally a DataState - it tracks the state/version of the 
> dataset so sync() gets and applies the right patches in order.
> 
> Your case seems a little different so it may not apply out-of-the-box - there 
> is a workflow between the two users that is managing the patch flow.
> 
> The DeltaClient class can also help - it is more focuses on managing and 
> interrogating the state of the state of the patch log.
> 
> So one way may be to run a patch log server and add your workflow specifics 
> to pull and apply patches.
> 
>Andy
> 
>> Thanks very much,
>> Chris

Re: Documentation/tutorial on using dates in Jena rules with GenericRuleReasoner

[Lorenz B.]

> b.  I think I actually tried the rule below and I didn’t get any 
> inference result. Don’t know if it’s my config, my rule or my data. I could 
> start a. by trying to provide a dataset and config file as well. Again, 
> anybody willing to hold my hand?

Works for me as expected:

|    Model m = ModelFactory.createDefaultModel();||
||    String s = "@prefix ns:  .\n" +||
||   "@prefix xsd:  .\n" +||
||   " ns:hasDeadline
\"2002-05-30T09:00:00\"^^xsd:dateTime .";
||    m.read(new StringReader(s), null, "Turtle");||
||
||    String rule =||
||    " [ruleMissedDeadline2: (?conference
 ?date) now(?now) greaterThan(?now, ?date)
" +||
||    "-> (?conference 
)]";||
||
||    List rules = Rule.parseRules(rule);||
||    Reasoner reasoner = new GenericRuleReasoner(rules);||
||    Model infModel = ModelFactory.createInfModel(reasoner, m);||
||    infModel.write(System.out, "N-Triples");|



> Give a shout.
>
> Thanks,
> Pierre
>
> From: Lorenz B. [mailto:buehm...@informatik.uni-leipzig.de]
> Sent: 17 May 2019 07:24
> To: users@jena.apache.org
> Subject: Re: Documentation/tutorial on using dates in Jena rules with 
> GenericRuleReasoner
>
> Hi,
>
>> Hi Lorenz,
>>
>> Thank you for your answer.
>>
>> Quick follow up.
>>
>> I think the issue for me is the documentation of the built-ins is too 
>> abstract or relies on understanding the source code. So I suppose, 
>> documentation / tutorial seems somewhat superfluous when you can do that – 
>> only I can’t understand what’s there and the source at the moment.
> I can see that it might be too abstract for people coming from different
> areas, sure. But, the question is who is able to provide such a tutorial
> and also who has the time. It's always a trade-off in Open Source
> projects like Jena - I guess most of the devs or other project related
> people here are not getting payed, and clearly such a tutorial for most
> if not all of the built-ins definitely needs some effort. Ideally, the
> community could take over those things, but looks like nobody ever wrote
> blog posts or tutorials about the Jena rule system and its built-ins.
>>
>>
>> 1. Yes, I seem to understand difference is a no go but I was wondering if 
>> there might be some work around coercing the dateTime to something else. I’m 
>> not sure I understood that very well but it looks like I can’t use functions 
>> in arguments of built-ins (so no xsd:year(?date) or whatever).
> I don't think you can use functions or expressions from the SPARQL
> engine resp. its XPath constructors. Both are totally different
> implementations I guess - but again, I'm not a developer, so I can't
> make a valid statement, except for looking into the code and the docs.
> From my point of view, only the mentioned built-ins from the docs are
> valid so far.
>>
>>
>> But then, on greaterThan, something should be workable if I have 
>> xsd:dateTime, no?
>>
>> What’s wrong with :
>>
>>
>>
>> [ruleMissedDeadline2:
>>
>> (?conference ns:hasDeadline ?date)
>>
>> now(?now)
>>
>> greaterThan(?now, ?date)
>>
>> ->
>>
>> (?conference ns:status ns:DeadlinePassed)
>>
>> ]
> Well I was clearly thinking too complicated, so yes, your rule should
> work given that the docs say
>
>> lessThan(?x, ?y), greaterThan(?x, ?y)
>> le(?x, ?y), ge(?x, ?y)
>>
>> Test if x is <, >, <= or >= y. Only passes if both x and y are numbers
>> or time instants (can be integer or floating point or XSDDateTime).
> I was more thinking about things like inferring the age of a person
> isn't possible right now, but would clearly be some nice to have feature
> such that you could have it as implicit fact in your KB without the need
> to change the asserted data every year.
>
>> 2. When you say extend the rule system, you mean adding a class using as a 
>> starting point something is in ..rulesys.builtins and adapting it and then 
>> rebuild all the jars. I’m using Fuseki, so I’d have to rebuild that too, 
>> yeah? Aside from the fact I’m not coding in java, this isn’t the easiest 
>> path for me at the moment.
> That's also something I can't answer properly. I mean, yes, you can
> create custom built-ins and register those or maybe create an overriding
> registry [1] ? But not sure, it looks like at least the overriding
> registry would have to be used by the rule parser, so I don't know how
> you would have to combine it with Fuseki. And in the end, yes, you have
> to repackage Fuseki I think as long as you modify the existing
> BuiltinRegistry.
>
> Maybe there is also some other kind of plugin system here, but that can
> only be answered by Andy, Dave, Adam, etc.
>
>
> [1] 
> https://issues.apache.org/jira/browse/JENA-1204
>
>> Many thanks,
>> Pierre
>>
>>
>> From: Lorenz B. [mailto:buehm...@informatik.uni-leipzig.de]
>> Sent: