Can you Offer a remote artefact an what does it mean?

[mielvds]

In the context of Cultural Heritage, we are working on a collection loan use case. One institution (lender) lends a collection of physical/digital objects (artefact) to another institution (borrower). The metadata about this collection and its objects is stored in the data pod of the lender, but the borrower can request access to the collection.

In this scenario:

• the service is giving access to the artefact X
• the service request is "can I have access to X?"
• the access request can be accepted or rejected

When translating this to the specification, is "can I have access to X?" an Offer with the artefact you want to have access to as object. It sounds a bit weird, but given the current vocabulary, this would be the best option. Of course, there would be a domain-specific type as well.

[mielvds]

Add example in the spec to cover this issue

[phochste]

This was discussed in the august 24 2002 meeting. The conclusion was that an 'object' can be about anything (local or remote). An Data Node typically ignores all Offer requests and other types of notifications that don't have a local artifact in the as:context. But, there can be an associated Service Node that does accept Offer .

The spec doesn't forbid these use-cases but it is not a typical value-added use-case.

[mielvds]

Thanks @phochste . The sentence

An Data Node typically ignores all Offer requests

did make me think of the discussion about Data and Service Nodes being purely logical roles. It might be worth taking the distinction a step further and indeed have the ability to be

• a 'spec-compliant Service Node' when only implementing sending Accept/Reject/Announce and reading Offer/CRUD/Announce
• a 'spec-compliant Data Node' when only implementing reading Accept/Reject/Announce and sending Offer/Announce (CRUD can be optional)

[phochste]

I think we need to land first on the event log spec to be able to do that. For now the spec only says what could happen when notifications are being send or received, not what should happen.

E.g. we could/should ..add something what the LDN Receiver does when it doesn't like a notification it reads.

Should we add something like a HTTP Link http://www.w3.org/ns/ldp#constrainedBy to be explicit what an LDN Receiver expects (or hint this can be done)? In the LDN Spec they provide such hints and how it is done by the Web Annotation Protocol. I don't that our protocol will go in the direction that goes so strict as do what 'Web Annotation Protocol' says, but probably it can provide a SHACL shape as constraint.

[mielvds]

I think we need to land first on the event log spec to be able to do that. For now the spec only says what could happen when notifications are being send or received, not what should happen.

I think that's irrelevant. Just like in the LD spec, you are a spec-compliant Consumer when you can follow the inbox link and make a GET request. The LDN spec says nothing about what Consumers are supposed to do with the response of the inbox.

E.g. we could/should ..add something what the LDN Receiver does when it doesn't like a notification it reads.

Should we add something like a HTTP Link http://www.w3.org/ns/ldp#constrainedBy to be explicit what an LDN Receiver expects (or hint this can be done)? In the LDN Spec they provide such hints and how it is done by the Web Annotation Protocol. I don't that our protocol will go in the direction that goes so strict as do what 'Web Annotation Protocol' says, but probably it can provide a SHACL shape as constraint.

I think it is interesting to at least describe the ability to do that. We were planning to create SHACL shapes of the payloads anyway, and that way implementations can be specific about our protocol.

[phochste]

I write this down as a todo to add an SHACL example how these contrains can be specified. Of course it is irrelevant what should happen. But I'm wary to write something like:

A spec compliant Data Node must accept Announce messages 

or

A spec complaint Data Node must send an 4XX when recieving an Announce message without an as:context about one of its own artifacts

I fear that the latter can't even be expressed in SHACL (and certainly not when an artifact is not something concrete).