Retire Sample Relations module
Opened this issue · 15 comments
Non-normative
Was only ever a thought bubble ...
Sorry I missed the session yesterday (was commuting between DK and FR).
Maybe I'm reading this wrong, but we need to keep the relatedSample for many domains.
And actually it's something we have in OMS in the Conceptual Sample schema model(see image below).
Happy to elaborate on why we need to keep this.
But I prefer a light contribution, in case I got this issue wrong
The SampleRelations modules is different to the OMS relatedSample property.
It has an association-class that can carry a role explaining the nature of the relationship.
(this is a standard 'pattern'.)
But to my knowledge it has not been used or deployed anywhere, so is pretty much an orphan where it is - https://www.w3.org/TR/vocab-ssn/#Sample_Relations
The OMS the related* relations all have a context for this role information.
In STA 2.0 we're planning a relation extension that has (among others) a RelatedFeature EntityType, since a Sample is just a specific type of Feature:
Also included: RelatedDatastream, RelatedObservation and RelatedThing.
I guess it may be useful to move this to the Feature level
I was looking at https://docs.ogc.org/as/20-082r4/20-082r4.html#_conceptual_sample_schema_model
The relatedSample association is direct, not an association class.
Same for all the other relatedXXX associations.
We don't have a general Feature class in SSN, only FeatureOfInterest.
So the Procedures, Executions, Systems etc do not have a common superclass to tie such a general association class onto.
And I don't want to get into doing a general application-schema model in the context of SSN, though (i.e. along the lines of ISO 19109).
We leave domain modeling to the domains. That's why FoI is a very sparse class.
Note that @kjano has proposed factoring out the Foi/Property part of the ontology into its own module - #191 (comment)
But there is this extra box attached to that relation: context:GenericName.
11.2.6. Association relatedSample
Requirement /req/sam-cpt/Sample/relatedSample-sem
A Sample the Sample is related to. If a reference to a related Sample is provided, the association with role relatedSample shall be used. The context:GenericName qualifier of this association may be used to provide further information as to the nature of the relation.
OK - I see that now. I didn't understand the UML idiom.
Yes, this clearly matches the Sample Relations ontology extension.
So is /req/sam-cpt/Sample/relatedSample-sem better related to https://www.w3.org/TR/vocab-ssn/#SAMPhasSampleRelationship ?
yes. That's why I was surprised in the first place
With our work on Water Quality I think we may be able to provide proof of implementation
The reason STA doesn't have a specific relatedSample class is because STA doesn't have a specific Sample class. There are relatedThing, relatedObservation and relatedDatastream classes. So if STA had a Sample class it probably also would have had a relatedSample class.
maybe the discussion about this in today's telco is more triggered by update procedures (here W3C is a bit different than OGC/ISO) than anything else.
several of us do know that we need to embark relatedObservation, relatedSample, relatedCollection (actually sosa:hasMember) etc... to answer to the use cases we face daily
but so far, the only short term proof of implementation we'll be able to provide will be under the OMS, STA paradigm.
provided we have a STA - JSON-LD output we could provide that proof of implementation (but maybe more medium term).
how do we do until then ?
- we remove those relatedxx properties: with the risk of having people neglect SSN/SOSA because those are missing ?
ex : I have those arriving at my desk in OneWater (ex : on a water sample bank) but we'll need time to refine the UseCase -> specify -> implement - or we keep them in with the mention that it's awaiting proof of implementation ?
You guys have more W3C spec experience than I do.
Just checking the relatedXXX associations on OMS, all 3 have the context on the association:
- relatedObservation
- relatedSample
- relatedCollection (can be both an ObservationCollection or a SampleCollection)
Does this mean we have to update the other relatedXXX?
You will recall that we added relatedObservation into SOSA, partly because OMS wants it, but also to support connections from Actuation and ActuationCollection to Observations that verify the value of the actuated property.
It is a simple property - no role or relationship-nature.
Arguably there should be a general capability relatedFeature or relatedEntity (as suggested by @hylkevds) which could come from the OGC/ISO 'General Feature Model' layer.
And, unless additional capabilities are needed for specific contexts, then there may be no need for specific properties.
Except the GFM doesn't exist in RDF and establishing it is definitely beyond the scope of SSN.
(Yes, I know we now have the FeatureOfInterest terms in SOSA-Common, but I'm reluctant to overload that further.)
(But as ever the choice of when to add a specialized property is something of an art. )
There is no harm in retaining the Sample Relations extension.
It was already in the 2017 edition after all, labelled non-normative.
While many of the cases mentioned could also be captured through isSampleOf relations, having a shorthand way to record the relationship-nature rather than through a Sampling with its SamplingProcedure and Sampler could be useful.
But we can't promote it so normative without implementation evidence.
Propose closing this with no action
However, perhaps we should retire the extra namespace and use sosa: for this capability?
Should we move the sample-relations terms into sosa: ?
sosa-rel:RelationshipNaturesosa-rel:hasSampleRelationshipsosa-rel:natureOfRelationshipsosa-rel:relatedSample
Probably beyond the scope of SSN core concerns. Leave in extension module.
Related to #36.