[Esip-cor] Notifications

[John Graybeal]

Lewis,

I'm sorry, I am new to this terminology and technology so I need to ask more questions.

1) What does an "LDN IRI" represent? An ontology used to capture a set of notifications, or a single notification?  It seems the latter. (But then, see #3.)
2) Do I understand correctly that your inbox ontology represents a single message queue? So if you wanted a separate message queue, say, one for each ontology in COR, you would have hundreds of inbox ontologies?
3) Assuming Carlos correctly derived that each ontology with a UUID in it is a single notification, I think I understand how you are trying to label the ontologies. It still seems that there is a bit of overlap, in that what I would call the 'term' pattern in COR is being used for _both_ the ontology ID and the notification ID. (Except it seems we don't say anything about the notification *inside* the ontology, like <notificationX>  <createdBy> <personY> so this is a bit confusing too.) Perhaps closer inspection would reveal they are not the same ID, or my model of the elements is not right, or the triples display I am reading for the ontology is not complete, or I understand it all correctly and it actually makes perfect sense that way (just not to me).

It would help if the ontologies that are being created had metadata in them describe what they are, as (I think) I previously noted.

I think it is worth the mental exercise of playing scenarious that use this capability out in our heads before we go too far down this path. Keeping in mind COR's UI is designed to deal primarily with human-curated ontologies of concepts, what happens if it is also populated with:
 - content from a notification endpoint that receives a large number of notifications every day/hour/minute?
 - content from a large number of notification endpoints?
 - content via lots of different applications supporting notifications with various degrees of clarity?
Can the UI, as it is currently written,  support those scenarios in a way that is compatible with existing uses of the COR?

It feels to me like these are fundamental questions that we should discuss before doing much advertising of LDN within COR.  I'm sorry to want to slow things down, but I've spent several hours trying to understand the technology and this application of it, and I clearly do not understand it at all well yet. Given constraints on my time this week, some more time to share and appreciate the details will be very welcome.

John



On Feb 5, 2019, at 7:32 PM, Mcgibbney, Lewis J (398M) <Lewis.J.Mcgibbney at jpl.nasa.gov<mailto:Lewis.J.Mcgibbney at jpl.nasa.gov>> wrote:

Let me try and clarify.

  *   The ‘inbox’ is a named graph representing some metadata and a collection of all LDN IRI’s which have been passed to the LDN service.
  *   Upon a POST event to the LDN service, the ‘inbox’ ontology is updated with the new LDN IRI. This is followed by a new named graph being created with the content of the LDN.
  *   Regarding the IRI which represents an individual LDN, IIRC as per the LDN specification, LDN’s should be available from the inbox hence my reasoning behind creation of the UUID to represent and distinguish individual notifications.

========================
John Graybeal
Technical Program Manager
Center for Expanded Data Annotation and Retrieval /+/ NCBO BioPortal
Stanford Center for Biomedical Informatics Research
650-736-1632


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-cor/attachments/20190206/5964fbc8/attachment.html>