[Esip-cor] Notifications
Carlos Rueda
carueda at gmail.com
Tue Feb 5 17:43:39 EST 2019
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/5d7a7fb2/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/5d7a7fb2/attachment-0001.png>
More information about the Esip-cor
mailing list