Documentation of data model about periodo-data HOT 5 CLOSED

Here's something I tried to come up with today for an edit history, using the PROV ontology. The history key would live at the top level of the dataset, alongside periodCollections and define a graph with a number of prov:Activity classes. Each patch has an associated prov:Activity that "uses" an old dataset and a .jsonpatch to "generate" new versions of period collections. By doing this, we keep track of who last updated the dataset, as well as who last updated each period collection. This could be expanded to cover every period definition, but that seems like overkill, maybe.

This approach would require changing the dataset and the period collections so that they additionally have the type prov:Entity.

It's still missing information about who approved the patch (and when)- maybe that's not necessary?

  "@context": {
    "@base": "http://n2t.net/ark:/99152/",
    "Activity": "prov:Activity",
    "Entity": "prov:Entity",
    "Person": "prov:Agent",
    "by": "prov:wasAssociatedWith",
    "generated": "prov:generated",
    "history": "@graph",
    "id": "@id",
    "name": "http://xmlns.com/foaf/0.1/name",
    "prov": "http://www.w3.org/ns/prov#",
    "specializationOf": {
      "@id": "prov:specializationOf",
      "@type": "@id"
    },
    "time": {
      "@id": "prov:atTime",
      "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
    }
    "type": "@type",
    "url": {
      "@id": "http://xmlns.com/foaf/0.1/page",
      "@type": "@id"
    },
    "used": prov:used",
    "wasRevisionOf": "prov:wasRevisionOf"
  },
  "history": [
    {
      "id": "#change1",
      "type": "Activity",
      "time": "2015-05-22T22:34:50",
      "by": [
        {
          "id": "http://orcid.org/0000-0002-3617-9378",
          "type": "Person",
          "name": "Patrick Golden"
        }
      ]
      "used": [
        {
          "id": "p0d?version=1",
          "type": "Entity",
          "specializationOf": "p0d"
        },
        {
          "id": "#patch1",
          "type": "Entity",
          "url": "patches/1.jsonpatch"
        }
      ]
      "generated": [
        {
          "id": "p0244q7?version=2",
          "type": "Entity",
          "specializationOf": "p0244q7",
          "wasRevisionOf": {
            "id": "p0244q7?version=1",
            "specializationOf": "p0244q7",
            "type": "Entity"
          }
        },
        { ...all the other period collections affected by this patch... }
      ]
    }
  ]

Does this make sense?

from periodo-data.

OK, our conclusion yesterday was that yes, we should keep track of edits to all assertions and not just collections. Further, provenance information will live in a different place than the original file, so some of my proposal can be tweaked.

from periodo-data.

Changes we should make, regardless of how we specifically model this in the end (these are maybe more server-oriented issues):

• Serving past versions of all content (collections, assertions)
• Adding prov:specializationOf statements to past versions that refer to the current canonical version
• (Possibly) adding prov:wasRevisionOf statements to past versions that are not new

from periodo-data.

I'd like to work some of this out alongside the patch submissions/acceptance interface that will be complete soon. Should I just go ahead with what I proposed?

from periodo-data.

I'm mostly out of my depth here, but I liked the direction you were going on provenance modeling. The pignolo in me feels that we should probably include in the model a reference to who approved the patch, and when, for the sake of completeness, but if this would hold up the process, I'd rather drop it and have the process in place so that we can test it this month.

from periodo-data.