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 <http://purl.bdrc.io/graph/0686c69d-8f89-4496-acb5-744f0157a8db> . H graph <http://purl.bdrc.io/graph/3ee0eca0-6d5f-4b4d-85db-f69ab1167eb1> . H create <http://purl.bdrc.io/graph/b1167eb1-85db-4b4d-6d5f-3ee0eca0f69a> . H create <http://purl.bdrc.io/graph/0157a8db-acb5-4496-8f89-0686c69d744f> . 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 <http://purl.bdrc.io/graph/0686c69d-8f89-4496-acb5-744f0157a8db> . H graph <http://purl.bdrc.io/graph/3ee0eca0-6d5f-4b4d-85db-f69ab1167eb1> . H create <http://purl.bdrc.io/graph/b1167eb1-85db-4b4d-6d5f-3ee0eca0f69a> . H create <http://purl.bdrc.io/graph/0157a8db-acb5-4496-8f89-0686c69d744f> . 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
