[Esip-cor] Notifications

[Mcgibbney, Lewis J (398M)]

Hi John,
No problems. Replies inline

From: John Graybeal <jgraybeal at stanford.edu>
Date: Tuesday, February 5, 2019 at 11:20 PM
To: "Mcgibbney, Lewis J (398M)" <Lewis.J.McGibbney at jpl.nasa.gov>
Cc: Carlos Rueda <carueda at gmail.com>, "esip-cor at lists.esipfed.org" <esip-cor at lists.esipfed.org>, ESIP COR <mmi.mmiorr at gmail.com>
Subject: Re: [Esip-cor] Notifications

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.)
Yes it’s the latter.


  1.  Do I understand correctly that your inbox ontology represents a single message queue?
It’s merely a structured container which describes a collection of LDN’s. The LDN’s then exist as other individual names graphs.

  1.  So if you wanted a separate message queue, say, one for each ontology in COR, you would have hundreds of inbox ontologies?
The LDN service is not means to be an inbox for every entry in COR. It is just for the LDN’s. It’s disjoint from all other existing entries in COR.


  1.  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).
Carlos identified the bug which was causing me confusion. I’ll go and fix this and then hopefully things will become clearer.

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 agree on this John… I can create some of this by default and I will. Do you have suggestions for what you would like to see?
Again however I would argue that they LDNs are no ontologies. They are merely RDF graphs.

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,

Understood and yes I am very much game for engaging in that effort.

what happens if it is also populated with:
 - content from a notification endpoint that receives a large number of notifications every day/hour/minute?

I don’t see this as an issue. People can still search for the resource they want to find via the GUI query bar.

 - content from a large number of notification endpoints?

Again, I don’t see the issue here. People can still search for the resource they want to find via the GUI query bar.

 - content via lots of different applications supporting notifications with various degrees of clarity?

Same applies. Using COR as the backend for a LDN service does not take anything away from the requirements for COR in the first place.
https://esipfed.github.io/stc/UseCases/STCUseCasesAndRequirements.html

Can the UI, as it is currently written,  support those scenarios in a way that is compatible with existing uses of the COR?

Yes, I think it definitely can.

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.

No problem at all. I think this would be useful for us to spend some time discussing at a future committee telecon as well. I did however want to launch the LDN service before the telecon so we had material to talk about and an opportunity to address some bugs.

Given constraints on my time this week, some more time to share and appreciate the details will be very welcome.

Yes John, thanks for writing I really appreciate it.
Lewis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-cor/attachments/20190206/a06922b9/attachment.html>