Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Note about the subject IRI of the Activity #11

Open
csarven opened this issue Nov 7, 2024 · 8 comments · May be fixed by #17
Open

Add a Note about the subject IRI of the Activity #11

csarven opened this issue Nov 7, 2024 · 8 comments · May be fixed by #17
Assignees

Comments

@csarven
Copy link
Member

csarven commented Nov 7, 2024

In nodeSolidServer/node-solid-server#1799 , I mentioned that the Activity could use an HTTP URI or a bnode (with UUID values in the string).

I think the spec could use a Note for server implementers to consider what they might want to use where/when...

@CxRes
Copy link
Member

CxRes commented Nov 7, 2024

I am assigning this to you. Please propose a PR!

@csarven
Copy link
Member Author

csarven commented Nov 9, 2024

I think this is the relevant part:

id <xs:string>
an opaque identifier for the notification. Can be used to set Last-Event-ID in a subsequent PREP notifications request.

  1. If id is the subject of event/activity (at least for those that are represented in RDF using AS2 etc.), then it it needs to be a URI or a bnode. So, I think saying that it is a string may be an issue here.

  2. The id could be used as a value for Last-Event-ID but the description of the event should express that. So, there needs to be a property along the lines of "previous", e.g., http://www.w3.org/ns/iana/link-relations/relation. Not sure if you can find anything specific to "previous/last event" (unless you change the payload a lot more and get into collections/paging territory). Of course you can create one under solid/notifications vocab too - could introduce notify:prev and consider whether making it a subPropertyOf rel:prev makes sense. I don't see an issue using a URI including a unique path but you can follow up on that. https://example.org/activity/{uuid}, https://example.org/.well-known/genid/{uuid}, urn:uuid:{uuid}, _:{uuid} should do.

{
  "id": "urn:uuid:0798c962-1879-448f-af44-f83162a029be",
  "published": "2024-11-07T14:15:58Z",
  "type": "Add",
  "object": "/dokieli/inbox/fa6ec1e0-dd3f-4b1f-b915-6dc3311351af.ttl",
  "target": "https://csarven.localhost/dokieli/inbox/",
  "state": "W/\"7-rM9AyJuqT6iOan/xHh+AW+7K/T8\"",
  "http://www.w3.org/ns/iana/link-relations/relation#prev": { "id": "urn:uuid:ee641336-dfd4-4004-9ed2-c0ef0d11d844" },
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://www.w3.org/ns/solid/notification/v1"
  ]
}

@CxRes
Copy link
Member

CxRes commented Nov 9, 2024

So, I think saying that it is a string may be an issue here.

Will fix!


This is different from what I am trying to express with event-id. The objective here is that if there is a disconnection, you can set a Last-Event-ID header with the event-id of the last notification in your reconnection request, to resume notifications from that point (or send a full representation).

In Solid Notifications also we can use this, to send any pending notifications before continuing. Id can do that job too but server has a two-step process where it will internally determine which event generated the uuid and then send notifications from that. I suppose I should file an issue there. In any case, a resumption mechanic is something SNP can benefit from as well.


prev can be useful but, that's a separate issue.

@CxRes
Copy link
Member

CxRes commented Nov 9, 2024

See solid/notifications#199

@csarven csarven changed the title Add a Note about the subject IRI or bnode of the Activity Add a Note about the subject IRI of the Activity Nov 12, 2024
@csarven
Copy link
Member Author

csarven commented Nov 12, 2024

Noting here as well: on second thought, I would suggest against using bnodes. These events should have an identity, so stick to IRIs.

@CxRes CxRes linked a pull request Nov 12, 2024 that will close this issue
@CxRes
Copy link
Member

CxRes commented Nov 12, 2024

I have created PR#17 that fixes the Data Model with neutral language.

If you still feel strongly, we can add an advisory that implantations should use IRIs and not blank nodes.

@csarven
Copy link
Member Author

csarven commented Nov 12, 2024

I think that systems that use bnodes in the end may have a hard time dealing with them in auditing cases or recalling the notifications. My sense is that these activities need to be treated as unique and persistent identifiers. bnodes will pose a problem all around. I don't have implementation experience on this at this point obviously.

@CxRes
Copy link
Member

CxRes commented Nov 12, 2024

I think...

We need to discuss this in the context of SNP!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants