Monitoring and data collection protocols developed for an additional 11 modules**
Data collection beta app(s) developed supporting 8 modules*
Data exchange standards specification developed and published compliant to 8 modules*
Draft controlled vocabularies for 8 modules*
Publishing and access methods established for the controlled vocabularies and ontology
IT systems built including API End stage report prepared
Remaining draft monitoring and data collection protocols delivered
Surveillance protocol team
Data exchange standard specification published online with draft examples for 8 modules
Investigate if we should use PoolParty or not.
Provide examples of how the data collected will look like in RDF conforming to the TERN Ontology
This is related to the export function Andrew’s team is implementing (Luke)
Outcome
the updated data exchange specification document
defined format and structure to share data collected from 8 modules in a site-survey data exchange standard
Vocabulary & ontology viewer set up for DAWE
Vocabulary viewer shows for the 8 modules:
Observable properties
Methods
Due to the short time constraint, we might need to just manually create these by hand like we have done for the AusPlots Rangelands and CORVEG methods
Categorical values
From Andrew’s LUT APIs
Feature types
Instrument types
Attributes
Ontology viewer shows the core classes and their constraints
All vocabs have a resolvable URI
We can use a test persistent ID as a demo since DAWE has not established a governance group to decide what the persistent identifier namespace is yet
Beta app(s) satisfies the data collection needs of 8 modules.
Andrew
Beta app(s) shows full functionality and feeds into a proxy database.
Andrew
IT infrastructure supports electronic data collection and management in a single system.
Andrew
End stage report satisfies the requirements at paragraph 6 of this Schedule.
Team
Google spreadsheet: https://docs.google.com/spreadsheets/d/1RZ6cXVjOZZhMKlhYyLNg73FucLKoL7LxRb8sp7jqMBM/edit#gid=0
See https://www.w3.org/TR/skos-primer/#secextension
Update the vocabulary viewer to support best practices in extending existing vocabularies. We can use the FedX functionality of GraphDB to achieve this. FedX is a way to virtualise two or more GraphDB SPARQL endpoints into one virtual SPARQL endpoint. By doing this, we are not duplicating data. Instead, we are making a normal query to a single SPARQL endpoint that is federated across multiple GraphDB repositories.
Let’s say we are creating a profile of the TERN parameters vocabulary. In short, what happens is we simply define in a new concept scheme what parameters are in it without worrying about duplicating the concept (e.g. label, definition etc.)
What does this mean when creating the DAWE vocabularies?
We simply need to say a particular concept (which already exists in the TERN parameters vocabulary) also exists in the new DAWE observable properties vocabulary.
See the triple below. We are saying the subject http://linked.data.gov.au/def/tern-cv/78b617e9-cd18-40b7-ad38-efc30579e680 is in the scheme http://linked.data.gov.au/def/tern-cv/f8bb9908-9e8f-4e46-bebc-4a00c08afbe1.
<http://linked.data.gov.au/def/tern-cv/78b617e9-cd18-40b7-ad38-efc30579e680> skos:inScheme <http://linked.data.gov.au/def/tern-cv/f8bb9908-9e8f-4e46-bebc-4a00c08afbe1> |
The source of truth for categorical values are supplied via https://dev.core-api.paratoo.tern.org.au/documentation.
Reuse observable properties if it already exists in the TERN parameters list. If an observable property does not exist, create it in TERN’s controlled vocabularies system.
Identify feature types in the Ecosystem Surveillance protocol and map to the TERN feature types list.
Reuse attributes if it already exists in the TERN attributes list.
Translate the PDF/Word versions of the Ecosystem Surveillance protocol into a more concise machine-readable procedure as a controlled vocabulary.
Reuse from the TERN instrument types list.