Hello,
I tried to transform the piece of ngsi-ld, presented in the workshop, to another type of rdf. I used jena riot, but there was an error.
tmp$ /opt/apache-jena-3.14.0/bin/riot --output=TURTLE test.json
15:00:47 ERROR riot :: [line: 2, col: 11] Expected BNode or IRI: Got: [STRING:urn:ngsi-ld:AirQualityObserved:RZ:Obsv4567]

My question is now: is this file realy rdf or is my software not compatible yet? (since we use apache jena in java for production backend code)

tmp$ cat test.json
{
"id": "urn:ngsi-ld:AirQualityObserved:RZ:Obsv4567",
"type": "AirQualityObserved",
"dateObserved": {
"type": "Property",
"value": {
"@type": "DateTime",
"@value": "2018-08-07T12:00:00Z"
}
},
"NO2": {
"type": "Property",
"value": 22,
"unitCode": "GP"
},
"refPointOfInterest": {
"type": "Relationship",
"object": "urn:ngsi-ld:PointOfInterest:RZ:MainSquare"
},
"@context": [
"https://schema.lab.fiware.org/ld/context",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
]
}

Kind regards

We will need to foresee standardized lists of ObservedProperties. The possible options are to:

1. Leave the lists to be customizable to whomever exchanges data, as long as the properties are identified via a URI (e.g. SKOS:Concept)
2. Suggest which standardized lists to use in the specification
3. Create our own taxonomy or list from what is available

Current code lists that have been raised during the workshops are:

AIR

• PubChem
• Other suggestions?

WATER

• WISE: Full list can be downloaded as CSV under export section
• Darwin Core: Biology
• PubChem

Our understanding from the discussions during the workshops
Indicate a standardized codelist to use but leave the flexibility to define other properties should they not be present in the codel list that is proposed.

Please provide your feedback and preferred option in this issue.

Thanks!

Kevin

Feedback from proof of concept conducted by Harm Delva (Ugent - imec):

The usage of ObservationCollection is a good idea as it makes the data much more clear instead of just using loose SSN/SOSA observations.

Currently the used URI does not seem to be in line with the one specified in the extensions, namely: http://www.w3.org/ns/sosa/ObservationCollection.

The shape attribute seems to be missing in the publication while it is present in the diagram.

To do: add shape attribute to SpatialSamplingFeature

A good number of ISO O&M URIs are used in the model but don't seem to exist. The URIs are correct according to the documentation (https://github.com/ISO-TC211/GOM), but don't seem to resolve.

SOSA's Observation is defined as a subclass of the ISO definition, so is there any reason why not just the SOSA version is used?

We will need to find a a on how to differentiate regular observations from observations related to emissions (for example stack emissions). C

WATER
Currently the featureofinterest details the types of water bodies for example, ground water, lake, ...

AIR
For Air we currently only have one FeatureOfInterest, namely 'air'.

How is this managed in other models?

We suggest expanding the Observations class with other subtypes on top of Measurement. ISO O&M suggests the following subtypes:

• Measurement (value + unit)
• CategoryObservation (classification)
• CountObservation (count)
• TruthObservation (Boolean)
• TemporalObservation (when does the observed characteristics occur)
• GeometryObservation (where does the observation occur)
• ComplexObservation (complex results)
• DiscreteCoverageObservation (timeseries)

Please let us know if this is a change you are interested in.

VLIZ' feedback on the air & water definitions: Definitions main classes & Origins.xlsx

Feedback from proof-of-concept of Harm Delba (Ugent - Imec)

Some extensions of SOSA seem less useful to me personally. For example, it is already difficult to find the definition of hasUltimateFeatureOfInterest because it is defined in a separate document. But when I look at the definition, you might as well use a SamplingFeature.sampledFeature property to make the link with the general feature of interest.

Currently we have not modelled out Feature but it looks like this may be needed to cover some of the use cases that were proposed.

Water
For water, we found that WISE proposes the following subdivision:

• Coastal Water
• Groundwater body
• Lake water body
• Marine waters
• River water body
• Territorial waters
• Transitional water body

-> Initial feedback during the workshop pointed out that this list may not be complete and leaves out other water feature types such as sewer water, wastewater...

Is there another standardized list that is complete for water and includes the other subtypes that are needed?

Air
A similar requirement may be needed for Air as well to cover use cases such as stack emissions from industry.
Is there a standard that refers to the specific feature types for Air?

See https://purl.eu/doc/applicationprofile/AirAndWater/Core/kandidaatstandaard/2021-10-01#Repeatability

There are multiple ways of depicting variation of data in one or more dimensions:

• W3 Cube was referenced in TW1.
• SOSA extensions Observation collections. This has already been added as part of the core model.

The current implementation of SOSA extensions ObservationCollections allows to make aggregations of data in 1 or more dimensions through the use of Feature of interest/ultimate feature of interest, phenomenon time, observed property, sensor, used procedure. The addition of an identifier to the observation collection will also allow any other arbitrary grouping of observations.

Is this enough to group observations? Do we need to add other aggregations?

DwC, the Darwin Core, delivers good formats/standards/framework for biology data.
https://dwc.tdwg.org/
https://rs.gbif.org

GBIF can be a resource for checklists/taxonlist.
https://www.gbif.org/dataset/search?type=CHECKLIST
e.g. https://www.gbif.org/dataset/search?type=CHECKLIST&publishing_country=BE to search "Belgian" checklists.
Data is provided through webservices.
(It is also possible to publish checklists on GBIF.)

GBIF has a tax backbone, an integration of different sources.
It could be used as a core reference.
GBIF Backbone Taxonomy

GBIF has tools, such as a data validator, a name parser, species matching against the backbone ...

We suggest adding an extra class that allows tracking ‘Specimen’. There are two possibilities:

• The WISE model allows pointing towards physical samples by creating two classes: SpatialSamplingFeatures, Specimen.
• SOSA goes more into details by adding SOSA Sampling (the activity of sampling) and SOSA Sampler (the specific instruments used).

Please let us know which option should be pursued.

The URI for WeatherObserved in the domains Air and Water points to a deprecated Fiware data model. The replacement model (smartdatamodels) doesn't seem to define a new URI though.

URI:
https://uri.fiware.org/ns/data-models#WeatherObserved

Specification:
https://purl.eu/doc/applicationprofile/AirAndWater/Air/kandidaatstandaard/2021-10-01#WeatherObserved
https://purl.eu/doc/applicationprofile/AirAndWater/Water/kandidaatstandaard/2021-10-01#WeatherObserved

Relevant links:
https://fiware-datamodels.readthedocs.io/en/latest/Weather/WeatherObserved/doc/spec/index.html
https://github.com/smart-data-models/dataModel.Weather
https://smartdatamodels.org/context.jsonld