-
Notifications
You must be signed in to change notification settings - Fork 2
Summary of Australia Face to Face
See intro pragraphs in 4-overview.adoc for some high level summary of meeting outcomes.
- O&M / SOSA Features
- HY_Features
- WaterML2 Features
- TimeSeriesML Features
- SoilIEML Features
- GWML2 Features
- Other Domain Feature Models?
- label / prefLabel
- description
- version
- definedBy (owner)
- sameAs
- featureType or dataType
- preview geometry
- Sampling / Sampled feature
- Observed property
- Phenomenon time (range)
- Procedure / method
- Simple topology
- HY_Features topology
- GWML2 Topology
Rest operations or graph views (defined as resolved shapes) to encompass the above.
- Basic
- For a given feature, give me the type and name.
- Summary
- For a given feature, give me all the properties (predicates) of it as a flat list.
- Feature Preview
- Views generally displayable basic information for a landing page.
- For a given feature, give me a useful understanding of what it is and/or what monitoring data it has.
- Should support a page with a map, a plot, some core O&M metadata, and a link to the network view.
- Acts as an environmental (monitoring-related) feature landing page with best-practice elements for landing pages.
- Network
- For a given feature, give me the features it is related to through topology, hydrology, or monitoring relationships.
- Should support a page with a map, links to topologically-related features,
Accross the IE, we should try to reccomend only things that are sufficiently core / standard that implementators can use them without competition with other aspects of an application. With a goal of a "general" app being designed to support only what's in this best practice (ignoring other content) but still functioning for the general monitoring of domain features problem.
- Identifiers and URLs for the IE may be temporary and concerns related to governance and publication will be worked around as they are not the focus. Some comentary about the importance of these issues may be included in the ER.
- We will have a feature type catalog hosted by someone but it may not be permanent.
- Our default encoding will be JSON-LD, ttl is secondary.
- Geometry will be limited to one "preferred" geometry per feature. Multiple representation should be the subject of future work.
The topic of what to return when accessing a non-information resource that has multiple information resources available came up several times. Alistair will attempt to summarize a strategy in detail. The following ideals can be used to guide us in this. We are not going to be able to solve the issues surrounding this, but will have to make some assumptions and possibly reccomendations. A strategy to move forward on the landing page issue:
Reccomend ONLY things that are:
- possible in existing infrastructures
- reccomended as a best practice elsewhere
- useful for the use cases we are working on
Develop a one-off IE template of features and properties we intend to include. The template should be something that an IE participant can easily convert basic geospatial data types into. Code to create static linked data documents based on the template could be used to iterate on the encoding and generate consistent files for all contributed content.
One suggestion was to use GeoJSON for geometry and attributes because github handles it nicely. A mapping file that indicates the GeoJSON attribute to map to a given predicate would be provided by the contributor of the data in question.
No concensus was found, but this will be a topic of discussion in Tuscaloosa.
- Address WFS issue related to identifiers to make it work in a resource oriented way.
- Try to convince people to set gmlids more correctly in WFS 2 or implement stored queries that expose a query parameter. (resource oriented WFS pattern)
- Change request to WFS 2+ to allow gmlIdentifier to be a query parameter.
- Still need to talk about evaluation. What do we expect these files to be able to do? This should be a topic in Tuscaloosa that gets finalized in St. John.
- Need to determine use case data contribution template and process. This should be started in Tuscaloosa and finalized in St. John.
The following are summary notes from face to face discussions at meetings in Canberra on June 2 2017. Participants included: Ingo Simonis, Jonathan Yu, Alistair Ritchie, Rob Atkinson, Byron Cochrane, David Blodgett.
- Express links between data (as data) rather than assume that clients know how things relate or can figure it out.
- "Crawlable" linked data for automated updating of catalogs (registries) of domain features and monitoring features.
- Current services are limited in how you can view the data behind them. You (a client) need to know how to figure out what to ask for.
- If we balance REST+JSON with just enough linked open data principles we should end up with something robust and easy to adopt using typical web technologies.
- “just enough” semantic annotation that allows us to traverse links to and among monitoring data and domain features.
- Identifier permanence / referential integrity and implementation patterns to address it.
- Arrangements around discovery of inbound and outbound links. Links are the responsibility of the data provider only.
- Permanent identifiers and referential integrity ("the Web is perfect") but we know its not so we are going to create static outcomes.
- We will have a feature type catalog hosted by some authority but it may not be permanent.
- Static outcomes such that if things don't work in the future, it doesn't matter.
- O&M / SOSA
- HY_Features
- GWML2
- GeoSciML
- SoilIEML
- TimeseriesML
- Linked Data Best Practice https://www.w3.org/TR/ld-bp/
- Data on the web https://www.w3.org/TR/dwbp/
- Spatial data on the web https://www.w3.org/TR/sdw-bp/
- Data exchange working group https://www.w3.org/2017/dxwg/wiki/Main_Page
- ShaCL https://www.w3.org/TR/shacl/
- DCAT https://www.w3.org/TR/vocab-dcat/
- Linked Data Platform? https://www.w3.org/TR/ldp/
- Linked Data API https://github.com/UKGovLD/linked-data-api
There was a discussion of some of our grounding use cases and user stories. It has been documented in the following diagrams. Please only view the documents at these links. Fork the repository and edit from your own fork for the time being, the group still needs to discuss diagraming and contributions.
Use Case 1
Use Case 2
Use Case 3
Use Case 4
Use Case 5
The following summarize a broad reaching conversation about scope of technical content to be considered from June 5th, 2017. Participants included Simon Cox, Jonathan Yu, Paul Box, Alistair Ritchie, and David Blodgett.
We imagine two themes to what we are bringing together: monitoring features and domain features. The following two sections summarize our conversations about scope for each "entry point".
- Feature of interest / sampledFeature
- Observation (summary)
- result (application profile + encoding + link)
- phenomenonTime (range)
- observedProperty (title + link)
- Related sampling feature(s)
- See general domain feature scope for use in feature of interest and domain feature "tell me what you are".
- Hydro Topology (HY_Features GWML2)
- Foundation Spatial Data Framework
- Simple Features Topological Relationships: http://www.opengeospatial.org/standards/geosparql
- Could use a simple skos relationship as well. Could be very meaningful in context.
- Domain features related to related monitoring features such as soil moisture in a watershed.
When considering a domain feature in the context of a monitoring feature or related domain features, we imagine including the following content.
- Type
- focused on the instance level
- label / name
- geometry (optional / "preview" view)
- Our default encoding will be JSON-LD.
- ttl will be a secondary encoding we intend to use in the IE.
- May try to test aliasing to introduce linked data predicates in plain JSON.
- Geometry will be limited to one "preferred" geometry per feature (for the sake of simple visualization).
- Multiple representation of the same physical thing in general should be the subject of future work.
- Features will also only be referenced from a single ontology (not two).
- Linked Data API "view"s to see topology around a feature or description of the feature and it's properties. See "alternates" concept here: https://confluence.csiro.au/public/SIRF/sirfcrossref for more.
- "tell me what you are." "Tell me who you know"
- Can we use swagger to document our resources in ELFIE?
- We could mock a bunch of interfaces and use swagger to document how we've done things.
The following are notes from a conversation on Tuesday June 6th between Alistair Ritchie, Jonathan Yu, and Dave Blodgett, with Simon Cox stopping in a few times. This builds on the material above, focusing in on a bit more technical perspective of what we're after. An important point here is that default or naive behaviors are not in scope for ELFIE. Here, we are interested in defining some best practice "views" of monitoring and domain features that give a "just enough" annotation to connect and use these data. Also worth noting is that we largely see use of a resource oriented approach (urls go to well-described instances, not services).
- "viewers" are a defined set of properties from a graph that you want to actually expose.
- There are "basic" (type and label), "description" (full "flat" model for a single entity)
http://.../uri -- Default behavior is not constrained by ELFIE practices as long as it gives access to the "views" discussed below.
/uri?_view=* -- see below for what "views" we imagine providing.
-
feature_preview: view generally displayable basic information for a landing page.
- label, prefLabel, description, version, definedBy (owner), sameAs, featureType, etc.
- "linked open vocabularies" has a set of "registration" properties. https://lov.okfn.org/dataset/lov/. (look for other examples e.g. from DXWG)
-
network: Feature-topology-and-monitoring view that displays a feature, it's spatial topology (if known), and domain topology (hydrology and monitoring).
- Forms the "network" of related features around a given feature.
- "Core" would be a small set of spatial topology operators. Consider having a basic version of a topology view that only shows "related".
- Extend with domain topology that could be related to the more basic topology.
- Note that inclusion of other properties is encouraged and implementors can ignore things that aren't in the recommendation.
- Address WFS issue related to identifiers to make it work in a resource oriented way.
- Try to convince people to set gmlids more correctly in WFS 2 or implement stored queries that expose a query parameter. (resource oriented WFS pattern)
- Change request to WFS 2+ to allow gmlIdentifier to be a query parameter.
- Need to point to some kind of practices around other views that may be useful e.g. "alternates" views. It's beyond the scope of this IE -- see DXWG?
Covered notes above -- notes below are stream of consciousness.
Discussed the issue of linking to a feature URI which redirects to a single representation of the feature, which leaves open the potential for options when you do a get against a non-information resource (Range 14 Decision).
There is a balance to be struck between global identity owned by the actual data owner or a proxy that is in the business of minting identity and less permanent proxy identity that's minted in the application space. Cross enterprise systems of linked data versus application-specific systems of linked data.
Discussion of how the domain and monitoring feature focused content is related to "feature_preview" and "network". The two views should be seen as core and the monitoring feature focus and domain feature stuff should extend the core.
We don't intend to say anything about "default" behavior or the "alternates" view. We don't want to say anything about landing page behavior. We need to state our assumptions and how we intend to move forward. Alistair put his hand up to write it up.
Talked through the model for contributing data to ELFIE and the way we are going to generate artifacts according to our in-design data product specification.