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

Fri Jan 25 11:42:12 EST 2019

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/bc08243c/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/bc08243c/attachment-0001.png>