Alternative interpretation of artefacts possible

In the December 1 version of the spec in section 2, 4 and 5 the artefact is viewed as a resource (or an aggregation of resources) on a Pod that undergoes some status changes, due to services provided by service hubs.

On Alice's pod there is an artefact A that goes through status changes: Registered , Certified , Archived, Disseminated, Commented. The modelling gives theses statuses a name (currently this is free text , but it should be a vocabulary of changes).

But this is not all that can happened in the network of Pods and Service Hubs. In the creation of a value chain the act of registering, certification, archiving , dissemination, commenting doesn't only changes the state of artefact A, there are other things added to the network that are not modelled: all these actions generate artefacts by itself on the service hubs. Examples of such a new artefacts:

A registration of a publication results in the publication of a registration page with added knowledge and results of business processes of this process. E.g. a CRIS system adds a lot of metrics and data for a registered publication. The registered publication artefact Reg(A) is not just A with a status change, it is a new entity in the network.
One can view the value added services as a sort of digital approval with a stamp , signature "We hereby declare that Artefact A is registered on date XYZ by Alice and it is approved by thus and so, signature etc".
These are the auxiliary artefacts that have their roots with Artefact A, but are not the same, that create the extra value .that gives a researcher reputation in a field.

These are the ServiceHub artefacts that are send back as Announce's to the Pods. It is not only about the fact that something is registered or certified .

Can't really pinpoint the exact question or issue here, but some thoughts:

In the December 1 version of the spec in section 2, 4 and 5 the artefact is viewed as a resource (or an aggregation of resources) on a Pod that undergoes some status changes, due to services provided by service hubs.

Depends on what you consider a status change, but yes.

On Alice's pod there is an artefact A that goes through status changes: Registered , Certified , Archived, Disseminated, Commented. The modelling gives theses statuses a name

It's just an example and probably not a perfect one :) The specific domain should define the possible events (might be statusses, might be something else) to support whatever application they want to have.

(currently this is free text , but it should be a vocabulary of changes).

Indeed.

But this is not all that can happened in the network of Pods and Service Hubs. In the creation of a value chain the act of registering, certification, archiving , dissemination, commenting doesn't only changes the state of artefact A, there are other things added to the network that are not modelled: all these actions generate artefacts by itself on the service hubs.

Exactly, and this is also why I had touble fitting in an interaction event like "Commented" or "Reviewed" as mentioned in https://github.com/MellonScholarlyCommunication/spec-notifications/issues/22

Examples of such a new artefacts:

* A registration of a publication results in the publication of a registration page with added knowledge and results of business processes of this process. E.g. a CRIS system adds a lot of metrics and data for a registered publication. The registered publication artefact Reg(A) is not just A with a status change, it is a new entity in the network.

Yep! but that has no impact on the fact that an artefact was registered, no? It's a new artefact with its own events.

* One can view the value added services as a sort of digital approval with a stamp , signature "We hereby declare that Artefact A is registered on date XYZ by Alice and it is approved by thus and so, signature etc".

* These are the auxiliary artefacts that have their roots with Artefact A, but are not the same, that create the extra value .that gives a researcher reputation in a field.

Yes, and that's why these artefacts should link to eachother.

These are the ServiceHub artefacts that are send back as Announce's to the Pods. It is not only about the fact that something is registered or certified .

Absolutely, but whould that impact the lifecycle and thus the event log of the original artefact? Up to now, I considered it as information in two contexts (not sure if that's the right word):

lifecycle context: notable lifecycle events that give an artefact a certain value or indeed, status.
artefact context: the way artefacts are related to each other, eg. A is a registration page of B

I think context 1 is what the event log covers, but we should think about how to manage context 2.

It is not clear for me from the examples in the spec (and the model) ..given an Artefact A and the Event Log of Alice's pod how a machine can figure out that there is a Reg(A) related artefact on the Service Hub website.

In the examples I don't see this link , the value chain:

<#1> a daen:LifecycleEvent;
    dcterms:title "Artefact was registered.";
    prov:startedAtTime    "2011-07-14T01:01:01Z"^^xsd:dateTime;
    prov:endedAtTime      "2011-07-14T02:02:02Z"^^xsd:dateTime;
    daen:artefact <http://example.org/artefacts/1>;
    daen:executor <http://example.org/registrar>.

I read above that an executor did some registration event, but I don't know what. The Service Hub will not tell that either? Events Logs are discovered via the artefacts, but it is unknown what artefact needs to be discovered at the side of the service hub.

In the mellon use cases I would assume that Alice's Event Log should contain the backlink:

<#1> a daen:LifecycleEvent;
    dcterms:title "Artefact was registered.";
    prov:endedAtTime      "2011-07-14T02:02:02Z"^^xsd:dateTime;
    daen:artefact <http://example.org/artefacts/1>;
    daen:executor <http://registar.org> ;
    as:link<http://registar.org/registration/23813178> .

Or a proof that work has been done that resulted in something new:

<#1> a daen:LifecycleEvent;
    daen:artefact <http://example.org/artefacts/1>;
    daen:action RegistrationEvent
    prov:endedAtTime      "2011-07-14T02:02:02Z"^^xsd:dateTime;
    daen:executor <http://registar.org> ;
    as:link <http://registar.org/registration/23813178>; 
       <https://w3id.org/security/v2/proof> [
         ...signature...
    ].

Same for interaction events. I only can know that Bob made a comment but can't figure out what comment or review Bob made.

There has to be a mechanism to proof what is in the Event Log is really true. There are no proofs or back links to the service hub to proof an event has really happened.

It is not clear for me from the examples in the spec (and the model) ..given an Artefact A and the Event Log of Alice's pod how a machine can figure out that there is a Reg(A) related artefact on the Service Hub website.

In the examples I don't see this link , the value chain:
<#1> a daen:LifecycleEvent;
    dcterms:title "Artefact was registered.";
    prov:startedAtTime    "2011-07-14T01:01:01Z"^^xsd:dateTime;
    prov:endedAtTime      "2011-07-14T02:02:02Z"^^xsd:dateTime;
    daen:artefact <http://example.org/artefacts/1>;
    daen:executor <http://example.org/registrar>.

In PREMIS Events, you'd have evRole:out, which is a subproperty of prov:generated. You can put:

<#1> a daen:LifecycleEvent;
    dcterms:title "Artefact was registered.";
    prov:endedAtTime      "2011-07-14T02:02:02Z"^^xsd:dateTime;
    daen:artefact <http://example.org/artefacts/1>;
    daen:executor <http://registar.org> ;
    prov: generated <http://registar.org/registration/23813178> .

or similar to the other properties, we can have daen:out rdfs:subPropertyOf prov: generated

I read above that an executor did some registration event, but I don't know what. The Service Hub will not tell that either?

The original reasoning was probably that just knowing something was registered and by who is enough. If I follow the link to the Service Hub's event log, and that one tells me the same, that's enough proof.

Events Logs are discovered via the artefacts, but it is unknown what artefact needs to be discovered at the side of the service hub.

A link should be added in the metadata of the artefact, not of the event. When a Service Hub has announced the Registration to Alice, it probably includes a link to http://registar.org/registration/23813178. Alice would then add something like <http://example.org/artefacts/1> :registeredBy <http://registar.org/registration/23813178> and Service Hub would have <http://registar.org/registration/23813178> :registers <http://example.org/artefacts/1>.

In the mellon use cases I would assume that Alice's Event Log should contain the backlink:

<#1> a daen:LifecycleEvent;
    dcterms:title "Artefact was registered.";
    prov:endedAtTime      "2011-07-14T02:02:02Z"^^xsd:dateTime;
    daen:artefact <http://example.org/artefacts/1>;
    daen:executor <http://registar.org> ;
    as:link<http://registar.org/registration/23813178> .

So the question is: where's the backlink? In the artefact's metadata (miel) or in the event log (pat)? I see value in having both... PREMIS also has a relType:hasSource property to tie two resources together where one was generated from another by an event.

Or a proof that work has been done that resulted in something new:
<#1> a daen:LifecycleEvent;
    daen:artefact <http://example.org/artefacts/1>;
    daen:action RegistrationEvent
    prov:endedAtTime      "2011-07-14T02:02:02Z"^^xsd:dateTime;
    daen:executor <http://registar.org> ;
    as:link <http://registar.org/registration/23813178>; 
       <https://w3id.org/security/v2/proof> [
         ...signature...
    ].
Same for interaction events. I only can know that Bob made a comment but can't figure out what comment or review Bob made.

There has to be a mechanism to proof what is in the Event Log is really true. There are no proofs or back links to the service hub to proof an event has really happened.

Wasn't this going to be the security by redundancy principle? The more event logs I find with the same event (with a higher weight for trusted service hubs), the more proof I have that it actually happened? That said, a signature will probably increase the trust when an event is found at some third party, so I would definitely incorporate that.

I think we agree that the links to the service hub must be in the Event Log, otherwise there is nothing to check which events are about the same. It is mandatory for our project to able to compare events on the pod and the service hubs.

The signature version is an alternative, you don't compare events but compare signatures to trust inline information in the event log.

But al these things are indeed all provided by PROV. I just didn't see it in the examples in the document.

Yes indeed. I'll add the signature approach as an alternative/complimentary method

MellonScholarlyCommunication / spec-eventlog

Alternative interpretation of artefacts possible #9