[Esip-cor] Notifications

Tue Feb 5 16:53:10 EST 2019

OK, and I agree, the real potential issue is with how the LDN mechanism
should actually work in particular regarding scalability/manageability/even
convenience, etc.

In fact, it seems that every single notification becomes a registered
ontology in itself, e.g, one of the ones COR-notified in this thread:
    http://cor.esipfed.org/ont/ldn/inbox/29b29cdaeaea486eb3aa7267981429e2
I thought such LDN notifications would be added to the same, relevant
'inbox' ontology (thus creating new version of it).  Surely I just haven't
spent enough time to understand LDN.  Perhaps Lewis could give us some
instruction! ;)

Carlos

On Tue, Feb 5, 2019 at 1:25 PM John Graybeal <jgraybeal at stanford.edu> wrote:

> Carlos, the two were both related to the new LDN stuff.
>
> I *believe* the way the notifications in LDN work is by adding RDF triples
> to the registered ontology for that 'notification inbox'. (I'm sorry if my
> lack of time to dive deeper has made me an idiot in this case.)  So if
> there are a lot of notifications, the registered ontology will get a lot of
> new versions. This makes it more of a store in a message bus (read:
> dynamic) than a curated repository of information (read:relatively static).
>
> In that case I would soon lose interest in updates to that ontology in my
> inbox, because hey! Thousands of updates! So then we would want a change to
> the COR notification system so that some ontology notifications could be
> turned off, at least for some of us.
>
> Of course, I/anyone could create a filter in their mailbox. But I think
> you'd run into other concerns, as more inboxes get created and the number
> of messages being generated by COR soars.
>
> These are future worries, not imminent ones. (And they also come into play
> as more ontologies start getting managed more frequently and automatically,
> and as the world realizes these servers are a potential spam distribution
> networks.)  But we should expect to change our assumptions about how the
> system can be used.
>
> John
>
>
> On Feb 5, 2019, at 1:11 PM, Carlos Rueda <carueda at gmail.com> wrote:
>
> It seems there are two intermingled notification-related aspects at play
> in this thread.
>
> One related with the traditional notification mechanism supported by the
> COR/ORR (which actually originated the first email in this thread). Those
> are generated upon the actual registrations but queued in a way that reduce
> the number of emails in case of multiple registrations in a short period of
> time.
>
> The other related with Lewis' new LDN stuff, which I of course let him
> talk about as I just have a very basic idea of it ; )
>
> Carlos
>
>
> On Tue, Feb 5, 2019 at 9:44 AM John Graybeal via Esip-cor <
> esip-cor at lists.esipfed.org> wrote:
>
>> Well, since it already is a ''notification' (by polling) system, they
>> don't *have* to go anywhere. :-)
>>
>> I think it will be useful to see them for a little bit longer, so it
>> isn't urgent. The real question is, how can we turn off notifications for a
>> particular ontology? I think we are talking about a configuration setting
>> per ontology in COR.
>>
>> This brings another question to mind, sorry. Do I understand correctly
>> that what is happening is that each notification results in an ontology
>> update? Is the Python code doing the sorting of incoming notifications to
>> make sure none are dropped, and does it then have the option of batching
>> the ontology updates (if 5 notifications come in the same second, say)?
>>
>> John
>>
>> On Feb 5, 2019, at 8:33 AM, Mcgibbney, Lewis J (398M) <
>> Lewis.J.Mcgibbney at jpl.nasa.gov> wrote:
>>
>> ACK John.
>> Do you have a proposal for where notifications should go?
>>
>> Dr. Lewis John McGibbney Ph.D., B.Sc.
>> Data Scientist II
>>
>>
>>
>> On 2/4/19, 8:03 PM, "Esip-cor on behalf of John Graybeal via Esip-cor" <
>> esip-cor-bounces at lists.esipfed.org on behalf of
>> esip-cor at lists.esipfed.org> wrote:
>>
>>    Our version notification emails will have to be tweaked if this gets
>> popular!
>>
>>    John
>>
>>
>> On Feb 4, 2019, at 18:23, ESIP COR via Esip-cor <
>> esip-cor at lists.esipfed.org> wrote:
>>
>>
>> A new ontology version has been registered:
>>
>> IRI: http://cor.esipfed.org/ont/ldn/inbox
>>
>> Name: ESIP Linked Data Notifications Inbox Graph
>> Version: 20190205T022303
>> Owner: ~lmcgibbn
>> Submitter: lmcgibbn
>> Updated: 2019-02-05T02:23:03.000Z
>> Log: (not given)
>>
>>
>>
>> The following ontology has been registered:
>>
>> IRI:
>> http://cor.esipfed.org/ont/ldn/inbox/29b29cdaeaea486eb3aa7267981429e2
>>
>> Name: ESIP Linked Data Notification: 29b29cdaeaea486eb3aa7267981429e2
>> Version: 20190205T022303
>> Registered: 2019-02-05T02:23:03.000Z
>> Owner: ldn
>> Submitter: lmcgibbn
>>
>>
>> (You have received this email because your address is included in
>> /etc/orront/notifyemails)
>>
>>
>> ========================
>> John Graybeal
>> Technical Program Manager
>> Center for Expanded Data Annotation and Retrieval /+/ NCBO BioPortal
>> Stanford Center for Biomedical Informatics Research
>> 650-736-1632
>>
>>
>> _______________________________________________
>> Esip-cor mailing list
>> Esip-cor at lists.esipfed.org
>> https://lists.esipfed.org/mailman/listinfo/esip-cor
>>
>
> ========================
> 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/20190205/22b1ca36/attachment-0001.html>