LDaaS

From Earth Science Information Partners (ESIP)
Revision as of 13:00, January 8, 2019 by Lmcgibbn (talk | contribs) (Created page with "= Linked Data as a Service (LDaaS) = == Purpose == This document outlines the effort to, through the [http://cor.esipfed.org/ Community Ontology Repository] (COR), provide an...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Linked Data as a Service (LDaaS)

Purpose

This document outlines the effort to, through the Community Ontology Repository (COR), provide an LDaaS service to the Earth and Space Science Informatics community.

Why?

COR enables data publishers to publish structured data which can be interlinked and become more useful. As of early 2019 COR is mostly being used as a repository for ontologies and other vocabularies. Limited information exists detailing additional uses therefore users do not know what they can do with the COR and hence do not understand how it could be useful for them. There is much more the ESIP Semantic Technologies Committee (STC) could be doing with COR to promote and enable more widespread use of vocabularies and ontologies in knowledge-based systems.

What is LDaaS and how would it work?

Put simply LDaaS would be an ESIP hosted service operated by STC which would provide the underlying software stack and networking requirements to enable data providers to publish structured data as linked data using their own URI's. Either they purchase the URI's they wish to use or else COR creates them on demand. SWEET is the primary example of how LDaaS would work

* We chose and purchased a top-level domain namespace e.g. http://sweetontology.net
* We put in place the HTTP redirects such that any requests to the above namespace resolve to the COR-service which both hosts and serves the SWEET resources.
* The COR service also sits in the background enabling applications to query linked data resources via a standards-based query language over HTTP (SPARQL-over-HTTP).
* The COR additionally provides application-specific functionality such as content negotiation.

The existing COR administrators have documented how this works in practice. Essentially for each new resource, we replicate the document process which subsequently streamlines the publication process for data providers. They can then interact with data obtained through URI's as they would if they had provisioned a fully managed, correctly networked linked data software stack.

This takes the concept of COR as a community ontology repository to something entirely new.

Methodology

So, what are the proposed steps forward? STC are working on a small ESIP Labs pilot proposal which will demonstrate the LDaaS capability. As of early 2019 two suitable data providers/customers have expressed interest in using a hosted service as described above. These parties are detailed as follows

Point of Contact(s) Target Resources Additional Comments
Dr. Dalia Varanka, USGS Ontology for The National Map https://www.usgs.gov/core-science-systems/ngp/cegis/geospatial-semantics-and-ontology
Nicholas Car (CSIRO), Simon Cox (CSIRO), Rob Atkinson (CSIRO) and Joseph Abhayaratna (PSMA Australia) Australian Geocoded National Address File (GNAF) Ontology... and others Using the infrastructure tools we have used for systems like the Australian Geocoded National Address File, its ontology and similar datasets like the Australian Statistical Geography Standard, we deliver ontologies and Linked Data data via given or allocated URIs. One future option we are already considering is to polish up the tooling and methods we use to provide Linked Data-as-a-Service packages or managed environments for others wanting to deliver LD as we do. Also, we are using the LD infrastructure & tooling we use as an implementation of Profile Negotiation, as per our recent Dataset Exchange Working Group profiles work (see https://www.w3.org/TR/dx-prof/ & http://www.linked.data.gov.au/dx-prof-conneg/) which would be useful to deliver ontology and other LD content in different ways for different audiences. So the LD tooling (pyLDAPI) is under current development, in line with current standards development.

Once we have proved the concept, we can make a formal announcement to the wider ESIP community and other targeted communities.