Contents of Inbox and NonRDFSources

[csarven]

Raised by @dmitrizagidulin

Is everything that the Inbox URL references to is a notification (typically containing content in RDF)?

Considerations: Default LDP implementations may list everything in the container via ldp:contains. One case here is that, if that Container contains NonRDFSources, it'll be listed. This is probably not what we want. Then again, the Inbox container should probably watch out or filter non-RDF resources.

We might need to take this into account in how this is worded.

[dmitrizagidulin]

I think it's worth stating this explicitly: What is a notification? It's an RDF resource residing in an inbox. If it's listed via ldp:contains and it's an RDF resource, it's counted as a notification. (There may be other, non-notification non-RDF resources residing in an inbox as well, such as images etc).

[csarven]

Fair points. The spec is working its way up to say those things without setting hard restrictions. For instance, there was ldp:Inbox for the Inbox URL but that's taken out for the time being. Similarly, :Notification could be used on the notification URI to make that explicit (machine-readable). We ran into this issue in the Solid proposals and ended up with :notification and :Notification. Lets see if it still makes sense through LDN.

Aside: I'd like to keep in mind that this is an LD notification mechanism and not strictly an LDP notification mechanism. This requires more care / cleaning up in the spec I think.

There may be other, non-notification non-RDF resources residing in an inbox as well, such as images etc

The key phrase there is "residing in an inbox". I'm not sure if that's necessarily true. Put LDP aside for a moment. Is it still true that something that's typed with :Inbox will have a property/object to a non-RDF resource? What would that relation be?

From that angle, :notification makes sense i.e., it pointing only to a :Notification. ldp:contains less so since that leads to Inbox pointing to any type of resource.

Reopening to keep this in the radar. PR is welcome if all that's needed is change in wording. Otherwise, new issues should address things like :notification/:Notification and refer back to this issue.

[dmitrizagidulin]

Is it still true that something that's typed with :Inbox will have a property/object to a non-RDF resource? What would that relation be?

I'm not sure I understand the question...

[csarven]

Basically can an Inbox have properties other than notification. Should the relations be only to the notification or anything? Is it the inbox that refers to the 'attachments' or the notification itself. In that sense, the notification will point to the non-RDF resources, not the Inbox.

[csarven]

The intention of this spec is to keep it minimal i.e., an Inbox points to notifications (in RDF). Future specs can extend e.g., non-RDF notifications or attachments etc.

[dmitrizagidulin]

There is a fine balance between keeping a spec minimal, and making it easy to understand for developers...

[rhiaro]

I think it's worth stating this explicitly: What is a notification? It's an RDF resource residing in an inbox. If it's listed via ldp:contains and it's an RDF resource, it's counted as a notification.

This, we've got.

(There may be other, non-notification non-RDF resources residing in an inbox as well, such as images etc).

This, I don't know if we need to explicitly say this as a MAY, or just assume that the use of ldp:contains according to LDP spec implies this.

[csarven]

We now say:

Each notification URI MUST be related to the Inbox URL with the ldp:contains predicate. Each notification MUST be an RDF Source. If non-RDF resources are returned, the consumer MAY ignore them.

@dmitrizagidulin Is that satisfactory for this issue? We are not saying you strictly can't return a NonRDFSource from the Inbox, but if you do, that's outside the scope of the spec.

[dmitrizagidulin]

Yeah, that works! Thanks.