"sameAs" for Observation Collections of the NIR

[bsimons14]

In attempting to implement Issue #88 it is unclear what it means for two resources to refer to the same Non-Information Resource. For a spatial sampling feature such as a Borehole, it could be represented using json-ld GeoSciML:Borehole or json-ld GroundWaterML2:Borehole. Both contain construction information, drilling metadata, etc. specific to the bore/well. However, GeoSciML may also contain information about the features sampled, such as geology, groundwater, aquifer etc. I am comfortable that both of these are representations of the same NIR, and therefore if available as an "In-Band" format are both to be included under "sameAs". Similarly, a GroundWaterML:GW_Well representation/profile of the same NIR presents both the GWML2:Borehole information and the interesected features information. This also seems to belong under "sameAs". Less clear is the collection of observations made down the bore/well. To me these are just another way of representing information about the bore/well. In principle this collection could include all the bore/well construction, drilling etc. information as a collection of observations, rather than using a domain specific information model. Consequently, CeRDI have included these under the "sameAs" (https://geo.org.au/info/well/107972?f=json). I believe this is not just a function of the feature (a bore/well) being a sampling feature. I believe the same logic could be applied to the collection of observations made on e.g. a river system, soil profile etc. Although each individual observation is not a representation of the NIR, the collection of observations made on the NIR is.

[dblodgett-usgs]

Others can correct me, but I think this is an area where we need more work.

It seems like the observation collection should be linked to the borehole NIR through an SSN/SOSA property rather than sameAs, no?

e.g. we would say that https://geo.org.au/id/well/107972 sosa:isFeatureOfInterestOf https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/107972 ?

Looking here: https://www.w3.org/ns/ssn/ext/ we have: sosa:hasFeatureOfInterest schema:domainIncludes ssn-ext:ObservationCollection

So we could certainly say: https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/107972 sosa:hasFeatureOfInterest https://geo.org.au/id/well/107972

And over here: https://www.w3.org/ns/sosa/: sosa:hasFeatureOfInterest owl:inverseOf sosa:isFeatureOfInterestOf

So this all adds up?

[dblodgett-usgs]

Note we might also use a more general association, schema:subjectOf, for clients that don't know about sosa too.

[dblodgett-usgs]

Also need to look at the use of sameAs in the examples above.

[dr-shorthair]

Remember that the practical consequence of owl:sameAs is that the graphs are merged - i.e. all properties of both resources are shared. If this is a problem, don't use sameAs.

[jyucsiro]

However, looking at the json-ld context, schema:sameAs (https://schema.org/sameAs) is the specific property, rather than owl:sameAs (although in this issue, owl:sameAs is being discussed).

[bsimons14]

I understood we were using schema:sameAs to avoid the owl:sameAs issues. The 'looser' schema:sameAs gave us the flexibility to cater for the variations between say gsml:Borehole and gwml:Borehole (and I'd argue gwml:GW_Well and ssn-ext:ObservationCollection).

[dr-shorthair]

OK - sorry for confusing the issue. Any time I see sameAs I get a little nervous.

[dblodgett-usgs]

We have owl:sameAs in some of the contexts. We need to make sure we get it straight and address this concern.

[bsimons14]

At the risk of re-opening a whole can of worms we have looked into a number of times and thought resolved. Today's (25/2/2020) SELFIE meeting suggested that we are not using sameAs vs subjectOf to distinguish between in-band and out-of-band resources, we should stay well clear of owl:sameAs, and it is unclear what resources belong in schema:sameAs vs subjectOf. Instead, we should just use subjectOf for links to all data resources. The "@id" and "@type" vs "url" tags provide sufficient information to distinguish the various resources.

[dblodgett-usgs]

Right. This is separate from the in-band / out-of-band link issue.

but this: https://opengeospatial.github.io/ELFIE/json-ld/elf.jsonld uses schema:sameAs and this: switched to owl:sameAs https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld

I'll need to do some digging to figure out why or maybe @abhritchie remembers?

[dblodgett-usgs]

@bsimons14, with #98 open, can we close this as a clarification on the use of subjectOf and possibly some sosa properties?

[dr-shorthair]

I just noticed that you are still using the old version of SSN-ext ... because the graph URI https://www.w3.org/ns/ssn/ext/ resolves to a stale version of the RDF :-( It was all updated when the new Working Draft of SSN-ext was published in January. I've logged this issue to get it fixed.

The main difference is for you guys is that the new classes and properties are now in the SOSA namespace and ssn-ext: is no longer used - see https://raw.githubusercontent.com/w3c/sdw/gh-pages/ssn-extensions/rdf/ssn-ext.ttl

[bsimons14]

Closing as was morphing into multiple issues:

• owl:sameAs or schema:sameAs
• schema:sameAs or schema:subjectOf
• SOSA ssn-ext deprecation These are now listed as separate issues.