[esip-semantictech] Linked Data Notifications (LDN) and Software Implementations

Fri Jan 25 12:41:08 EST 2019

Tom,  Lewis, all

  So been following this thread.     I reviewed the LDN spec a bit and I was very interested in how it compares and contrasts to both Web Annotations protocol spec [1] and the PROV-AQ pingback [2].    Indeed, I could almost see PROV pingback migrating to this a bit.  (there are contrasts though too).

  I'm particularly interested in this since I am looking at making the EarthCube P418 Gleaner code [3] a bit more of a service.  Part of that is to allow people to submit sitemaps and test them against community established SHACL shapes.  I have bits of that working on my laptop now.   I was actually trying to resolve how to notify people when runs are done and also wondering if machine to machine notifications needed to be part of that.   To be honest, LDN seems a bit heavy and convoluted for what I want..  which would likely work with a simple webhook into github or slack for example.  Still, I wonder if I can get both with little extra code.   LDN might be interesting for actions based on new builds of the graph from indexing the involved facilities though.

   Additionally LDN looks very closely tied to the TBL / MIT Solid work.   I have a solid account at:  https://fils.solid.community/ and https://fils.solid.community/inbox/ for my inbox (as seen in the LDN notes).   Was chatting with Adam a bit about this this morning too and he set his up too (s/fils/ashepherd for his).  So these might make really nice targets for testing this with.

  So, if I can work in some LDN calls in my current work I will let people know...   the overall coding effort doesn't seem heavy.

Take care

Doug

[1] https://www.w3.org/TR/annotation-protocol/

[2] https://www.w3.org/TR/prov-aq/#provenance-pingback

[3] https://github.com/earthcubearchitecture-project418/gleaner

________________________________
From: esip-semanticweb <esip-semanticweb-bounces at lists.esipfed.org> on behalf of Narock, Thomas via esip-semanticweb <esip-semanticweb at lists.esipfed.org>
Sent: Friday, January 25, 2019 10:42:12 AM
To: Mcgibbney, Lewis J (398M); Gary Berg-Cross
Cc: esip-semanticweb at lists.esipfed.org
Subject: Re: [esip-semantictech] Linked Data Notifications (LDN) and Software Implementations

Thanks Lewis. I wasn’t aware of these. I’ll take a look.  Regarding your questions from a previous email

Which data format will the documents be in?

                I’d like to use JSON-LD. This is what the LDN spec discusses and I think JSON will already be familiar to developers in this area.

Are you planning to mint your own domain name space or are you just going to have COR generate URI’s for you?

I was going to have COR generate the URI’s for the new classes we are proposing. But, I would like to get feedback from @Gary Berg-Cross<mailto:gbergcross at gmail.com> and Charles on best practices for reusing existing ontology design patterns. I want to reuse the GeoLink Role pattern and maybe one other. Is there a preferred method of reuse?  Just reuse the original ODP’s URIs or create my own classes and URIs that follow the pattern with equivalent class relationships back to the original pattern?

From: Lewis Mcgibbney <Lewis.J.McGibbney at jpl.nasa.gov>
Date: Friday, January 25, 2019 at 12:38 AM
To: Tom Narock <tnarock at ndm.edu>
Cc: ESIP Cluster <esip-semanticweb at lists.esipfed.org>
Subject: Re: Linked Data Notifications (LDN) and Software Implementations

CAUTION: This email originated from outside NDMU. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Follow up here Tom, I’ve been doing some homework and came across the following implementations

LDN Sender and Consumer client libraries

https://github.com/solid/solid-notifications

https://github.com/trellis-ldp/py-ldnlib

LDN Receivers

https://github.com/jpcik/ldn-streams (I’ve not been successful in compiling this code)

https://github.com/albertmeronyo/pyldn (I’ve used this and it works well. I will most likely start implementing the code for COR backend integration)

Lewis

Dr. Lewis John McGibbney Ph.D., B.Sc.

Data Scientist II

Computer Science for Data Intensive Applications Group (398M)

Instrument Software and Science Data Systems Section (398)

Jet Propulsion Laboratory

California Institute of Technology

4800 Oak Grove Drive

Pasadena, California 91109-8099

Mail Stop : 158-256C

Tel:  (+1) (818)-393-7402

Cell: (+1) (626)-487-3476

Fax:  (+1) (818)-393-1190

Email: lewis.j.mcgibbney at jpl.nasa.gov<mailto:lewis.j.mcgibbney at jpl.nasa.gov>

ORCID: orcid.org/0000-0003-2185-928X

           [signature_554635968]

 Dare Mighty Things

From: "Mcgibbney, Lewis J (398M)" <Lewis.J.McGibbney at jpl.nasa.gov>
Date: Thursday, January 24, 2019 at 11:04 AM
To: "Narock, Thomas" <tnarock at ndm.edu>
Cc: "esip-semanticweb at lists.esipfed.org" <esip-semanticweb at lists.esipfed.org>
Subject: Re: Linked Data Notifications (LDN) and Software Implementations

Hi Tom,

Response inline line thank you.

From: "Narock, Thomas" <tnarock at ndm.edu>
Date: Friday, January 18, 2019 at 8:57 AM
To: "Mcgibbney, Lewis J (398M)" <Lewis.J.McGibbney at jpl.nasa.gov>
Cc: "esip-semanticweb at lists.esipfed.org" <esip-semanticweb at lists.esipfed.org>
Subject: Re: Linked Data Notifications (LDN) and Software Implementations

Hi Lewis,

I agree there are lots of interesting use cases for a Linked Data Notifications (LDN) architecture across ESIP projects. Thanks for keeping this discussion moving forward.

Our particular use case deals with provenance and its PROV encoding. We are interested in using PROV to encode climate resilience and climate mitigation decisions. There at least 3 efforts underway to semantically encode decision making [1][2][3]. [1] extends PROV to include decision related concepts. [2] is built off of formal decision theory research, but, as far as I can tell, it only currently exists in UML. USGS is interested in [2] and there seems to be efforts underway to encode it in OWL with possible links to PROV. In [1] Nick Car showed that [3] could be rewritten purely in PROV so we’ve been focusing on [1] as a lightweight encoding of decisions and following the progression of [2] for more detailed decision encoding. We’ll soon be submitting to COR our proposed extensions of [1] to make it more specific for climate decisions.

OK cool. Are you planning to mint your own domain name space or are you just going to have COR generate URI’s for you?

The connection to LDN is that once these provenance documents exist, we’d like to have a repository to submit them to

Which data format will the documents be in? COR can handle the following

JSON-LD

https://www.w3.org/TR/json-ld/

RDF/XML

https://www.w3.org/TR/REC-rdf-syntax/

Notation3

https://www.w3.org/TeamSubmission/n3/

N-TRIPLE

https://www.w3.org/TR/n-triples/

TURTLE

https://www.w3.org/TeamSubmission/turtle/

OWL/XML

https://www.w3.org/TR/owl-xml-serialization/

RDF/JSON

https://www.w3.org/TR/rdf-json/

and a means of notifying interested parties that a new decision exists. We think LDN is a straightforward means of providing these capabilities. Ultimately, we’d like to compare climate decision provenance and provide suggestions/recommendations for decision makers facing similar situations. Although, that seems outside the scope of LDN and would be a service built on top of it.

Yes I agree.

I would also mention that there’s another W3C spec (this one is a Note, not a Recommendation) called PROV-AQ, Provenance Answer and Query. Doug Fils and I looked at that one in the past for provenance submission and discovery. Having looked at both, I think LDN can provide the same functionality, is easier to implement, and works with JSON-LD, which a lot of developers are comfortable with. I think our use case would move forward faster with LDN, and the LDN spec aligns well with other ESIP use cases.

I agree. I am also confident that we could use COR to host any LDN as they are serialized as JSON-LD.

If you were to stand up an LDN instance I think we’d have a number of people willing to try it out.

OK, so I think we should do just that then.

Lewis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-semanticweb/attachments/20190125/d5a69b73/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3431 bytes
Desc: image001.png
URL: <http://lists.esipfed.org/pipermail/esip-semanticweb/attachments/20190125/d5a69b73/attachment-0001.png>