Update data models

[csarven]

Follows consensus of https://github.com/solid/notifications-panel/blob/main/meetings/2022-12-15.md

Resolves https://github.com/solid/notifications/issues/71 https://github.com/solid/notifications/issues/111 .

---

Preview | Diff

[csarven]

https://github.com/solid/notifications/pull/135/commits/b05cc76d3343321799c79322f4a95d28cbf12290 is based on consensus in 2022-12-20 minutes: https://github.com/solid/notifications-panel/pull/86

[csarven]

startTime and endTime are features and originally intended to be part of the notifications vocab and JSON-LD context. They are also however defined in AS2. Do we need to do alias magic for the context? How would we work it out in the notify vocab?

[elf-pavlik]

We could add non-normative text explaining shortly when subscription can be used and when available channels can be advertised in description resource. (this could also be tracked as separate issue)

Advertising subscription resources can be used to:

• create notification channel for protected resource, which relies on capability url to protect the channel
• create notification channel with specific features required by the subscribing client

Advertising existing channels can be used to:

• provide notification chennel for protected resource, which does NOT rely on capability url to protect the channel
• provide notification channel for public read resource, which does NOT need to by protected

[CxRes]

I would consider reconciling terminology section and data model sections. It looks like each term has it's own section in the document. It might make sense to just move the definition from terminology to that section and remove Data Model suffix. This way concepts are defined and specified in the same place, it should also simplify linking to those concepts.

I am not sure, I follow. Also, you need definitions ideally at the top of the document.

[csarven]

I'd like to merge this PR after updating it with alternatives to startTime and endTime ( re Re https://github.com/solid/notifications/pull/135#issuecomment-1361127017 ):

• start and end
• startDateTime and endDateTime
• startDate and endDate
• startAt and endAt
• dtstart and dtend
• from and until
• open and close

No doubt that there can potential be a clash. FWIW, startAt/endAt is not used in any vocab that LOV has on record. A bit harder to say for JSON-LD contexes. The Solid Notifications vocab and JSON-LD should probably stay clear of AS2, and possibly other things which may be potentially mixed with notifications and AS2, e.g., schemaorg, PROV-O, anything in/around Time Ontology, ical .. or some others?

Or maybe even something a bit more complex altogether and use an ObjectProperty that is an instance of an existing of an event type (ical or whatever..).

Or go in the direction of channelStart and channelEnd, or some other prefix/suffix.

Endless possibilities... but we need to decide in the next five minutes :)

[csarven]

Group considered the options and decided to go with startAt and endAt in 2022-12-27 meeting (PR to minutes follow.)

Feedback still welcome until TR release.