[Esip-cor] Notifications
Carlos Rueda
carueda at gmail.com
Tue Feb 5 17:46:56 EST 2019
Ah, correction!: /inbox/ does have references to the others, sorry:
<http://cor.esipfed.org/ldn/inbox/>
j.0:contains <
http://cor.esipfed.org/ldn/inbox/f4a24af13e754884938c8f1ddae0468a> ,
<
http://cor.esipfed.org/ldn/inbox/29b29cdaeaea486eb3aa7267981429e2> ,
<
http://cor.esipfed.org/ldn/inbox/12d10c93e25e4a39a0fa7496c413d842> .
On Tue, Feb 5, 2019 at 2:43 PM Carlos Rueda <carueda at gmail.com> wrote:
> http://cor.esipfed.org/ont/ldn/inbox/29b29cdaeaea486eb3aa7267981429e2 seems
> to me like it is only a single notification, but maybe I'm wrong. Here's
> the turtle version:
>
> @base <
> http://cor.esipfed.org/ont/ldn/inbox/29b29cdaeaea486eb3aa7267981429e2> .
>
> @prefix as: <https://www.w3.org/ns/activitystreams#> .
>
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>
> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
>
> <http://www.test.example/martin>
>
> a as:Person ;
>
> as:image [ a as:Link ;
>
> as:href <http://example.org/martin/image.jpg> ;
>
> as:mediaType "image/jpeg"
>
> ] ;
>
> as:name "Martin Smith" ;
>
> as:url <http://example.org/martin> .
>
>
> <http://www.test.example/blog/abc123/xyz>
>
> a as:Article ;
>
> as:name "Why I love Activity Streams" ;
>
> as:url <http://example.org/blog/2011/02/entry> .
>
>
> <http://example.org/blog/>
>
> a as:OrderedCollection ;
>
> as:name "Martin's Blog" .
>
>
> [ a as:Add ;
>
> as:actor <http://www.test.example/martin> ;
>
> as:object <http://www.test.example/blog/abc123/xyz> ;
>
> as:published "2015-02-10T15:04:55Z"^^xsd:dateTime ;
>
> as:summary "Martin added an article to his blog" ;
>
> as:target <http://example.org/blog/>
>
> ] .
>
>
> I also based my (quick) impression by looking at the list of recent
> submissions:
>
> [image: image.png]
>
> where, BTW, i don't see any cross-references among them .... (again,
> cursory review)
>
> On Tue, Feb 5, 2019 at 2:29 PM John Graybeal <jgraybeal at stanford.edu>
> wrote:
>
>> Carlos, if I am reading it correctly, your link points to a single inbox
>> ontology with a number of different notifications in it. The RDF statements
>> representing the notifications are made about different ontologies, but
>> they are just individual statements for that 1 inbox.
>>
>> There is a directory of all the (3 as of now) inbox ontologies at
>> http://cor.esipfed.org/ont/ldn/inbox. Presumably they have separate
>> purposes.
>>
>> @Lewis, FYI the links inside that directory do not successfully open the
>> respective inboxes, I haven't checked why.
>>
>> There is something odd about names of those 3 inboxes—the IRI for each
>> inbox does not follow the COR pattern (../ont/owner/ontologyName), but adds
>> '/' and unique identifiers after ontologyName:
>> ../ont/owner/ontologyType/ontologyID, where ontologyType is 'inbox'. It
>> would be Really Nice if ontologyType and ontologyID were merged like this:
>> inbox_abcdef123456789. Lewis, would that work?
>>
>> Also, it will be really nice self-documentation and advertisement for
>> this system if both the main inbox, and each of the invidual inboxes, have
>> really complete metadata. These fields are like an abstract and summary
>> metadata for a publication: they summarize the purpose and content of the
>> publication (inbox), point to the parent inbox, and so on. If they are
>> empty it makes other users wonder "what is this?", but not necessarily
>> using that language.
>>
>> John
>>
>>
>> On Feb 5, 2019, at 1:53 PM, Carlos Rueda <carueda at gmail.com> wrote:
>>
>> 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
>>>
>>>
>>>
>> ========================
>> 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/e347cf47/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 44867 bytes
Desc: not available
URL: <http://lists.esipfed.org/pipermail/esip-cor/attachments/20190205/e347cf47/attachment-0001.png>
More information about the Esip-cor
mailing list