Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross referencing to Common Modelling section #234

Open
sgrellet opened this issue Jul 10, 2024 · 13 comments · May be fixed by #276
Open

Cross referencing to Common Modelling section #234

sgrellet opened this issue Jul 10, 2024 · 13 comments · May be fixed by #276

Comments

@sgrellet
Copy link
Contributor

This issue is a spinoff of elements mentionned in #232 (comment)

Add explanation to spec doc explaining class=set interpretation - in Common Modeling Questions section - cross reference from hasFoI

Other cross-references to Common Modelling section may help the new comer to SSN/SOSA (and even to ontology world).

The purpose of this issue is to list where extra crossref could be added

@sgrellet
Copy link
Contributor Author

@rob-metalinkage : could you add here the exemple you developed during the session

@dr-shorthair
Copy link
Collaborator

Linked to #197 and #201

@dr-shorthair
Copy link
Collaborator

@KathiSchleidt
Copy link
Contributor

Some feedback/questions:
8.1 Quantity Values and Units of Measure
Why is unit:DEG_C instantiated in the 2nd example, not in the first?

8.2 Domain types and FeatureOfInterest
Could you define Execution while listing "Actuations, Observations, and Samplings" at the start, make it easier for fools like me to realize the definition of Execution ;)

8.3 Proximate and Ultimate feature of interest
Maybe add an actuation example?

Fig 24 - S1 missing hasProperty to OP1 (Sampling.hasResult missing hasProperty)

sosa:madeBySampler ex:thermalDrill2 ; --> sosa:madeBySampler ex:ThermalDrill2 ; (Capitalization issue)

8.4 Sample chains
Under 8.2 there's a statement "Note that this constraint does not require you to derive domain types as sub-classes of sosa:FeatureOfInterest. It could be argued that would be an error."
At the end of Example 4 we state ex:Antarctic_ice_sheet a sosa:FeatureOfInterest ;
?

8.6.2 Historical observations
Shouldn't sosa:hasResult ex:d77 ; --> sosa:hasResult ex:D77 ; ? Classes are capitalized (except this one)

Should we add an example of a historical observation transcribed from an old log-book? What's the result-time there?

8.7 Property definitions

§3 "A property may be made specific to a single feature of interest..."
While we've dropped the individual-specific Properties, in reality we often see the Property tied to the class of the FoI, e.g. Air-Temp vs. Water-Temp, exactly what I-ADOPT is about
Would it make sense to add an example where we have ex:SickChildTemperature defined as the Temp of any SickChild (or even just Child)

@dr-shorthair
Copy link
Collaborator

dr-shorthair commented Jan 28, 2025

@KathiSchleidt wrote (in email)

Some feedback/questions:
8.1 Quantity Values and Units of Measure
Why is unit:DEG_C instantiated in the 2nd example, not in the first?

I've added definitions of all the datatypes.

8.2 Domain types and FeatureOfInterest
Could you define Execution while listing "Actuations, Observations, and Samplings" at the start, make it easier for fools like me to realize the definition of Execution ;)

Done

8.3 Proximate and Ultimate feature of interest
Maybe add an actuation example?

Done - the first very simple example.

Fig 24 - S1 missing hasProperty to OP1 (Sampling.hasResult missing hasProperty)

The diagrams are incomplete, by design.
Also, a sample does not necessarily have the same properties as the sampled feature.

sosa:madeBySampler ex:thermalDrill2 ; --> sosa:madeBySampler ex:ThermalDrill2 ; (Capitalization issue)

Fixed

8.4 Sample chains
Under 8.2 there's a statement "Note that this constraint does not require you to derive domain types as sub-classes of sosa:FeatureOfInterest. It could be argued that would be an error."
At the end of Example 4 we state ex:Antarctic_ice_sheet a sosa:FeatureOfInterest ;
?

Example 4 is dealing with instances (individuals). The recommendation relates to classes. rdf:type vs rdfs:subClassOf.

8.6.2 Historical observations
Shouldn't sosa:hasResult ex:d77 ; --> sosa:hasResult ex:D77 ; ? Classes are capitalized (except this one)

d77 is not a class, it is an instance. No rules about these.

Should we add an example of a historical observation transcribed from an old log-book? What's the result-time there?

I think it is the date of the log. Can you give a likely example including the result value?

8.7 Property definitions

§3 "A property may be made specific to a single feature of interest..."
While we've dropped the individual-specific Properties, in reality we often see the Property tied to the class of the FoI, e.g. Air-Temp vs. Water-Temp, exactly what I-ADOPT is about
Would it make sense to add an example where we have ex:SickChildTemperature defined as the Temp of any SickChild (or even just Child)

Could you provide the I-ADOPT formulation for SickChildTemperature, and perhaps we could put it alongside the SAREF example?

dr-shorthair added a commit that referenced this issue Jan 28, 2025
@KathiSchleidt
Copy link
Contributor

Historic example (Riffed off Source)

  • Property: Air temperature
  • FoI: Station Hohe Warte (48.248491274780754, 16.355804145468635)
  • phenomenonTime: 04.04.1872 15:00
  • Result: 22.5
  • Observer: Mercury thermometer
  • resultTime?

Working on the I-ADOPT example but want Barbara Magagna's confirmation I'm correct before I sow confusion.

@oldskeptic
Copy link
Contributor

@KathiSchleidt How would we model Observer in Sosa? Sensor?

@sgrellet
Copy link
Contributor Author

@KathiSchleidt How would we model Observer in Sosa? Sensor?

@oldskeptic OMS:Observer would be Sensor here.

@dr-shorthair
Copy link
Collaborator

In response to commentary in this week's telecon, I've added a section of patterns for Time Series - see preview https://raw.githack.com/w3c/sdw-sosa-ssn/234-link-to-patterns/ssn/index.html#time-series

I show three patterns:

  1. explicit ObservationCollection
  2. result vector inline
  3. result as a link to a netCDF file (notional)

What do you all think?

Note that in the 2017 work there was discussion of use of RDF Datacube for complex data.
However, this didn't make it into the SSN Recommendation, and I'm not aware of widespread adoption of RDF Datacube, so I'm disinclined to introduce it here.

@KathiSchleidt
Copy link
Contributor

On "SickChildTemperature" and I-ADOPT, this would be represented as:

  • Property: Temperature
  • ObjectOfInterest: Child
  • Constraint on ObjectOfInterest: Sick

@dr-shorthair
Copy link
Collaborator

See https://raw.githack.com/w3c/sdw-sosa-ssn/234-link-to-patterns/ssn/index.html#new-property-definitions for I-ADOPT example

@dr-shorthair dr-shorthair linked a pull request Feb 4, 2025 that will close this issue
@dr-shorthair dr-shorthair linked a pull request Feb 4, 2025 that will close this issue
@KathiSchleidt
Copy link
Contributor

8.8.1 Catalogues of properties

Maybe also add some specialized property catalogues, e.g. GloSIS

Also - must these be semantic resources? If not, could provide examples as simple codelists from EEA

@KathiSchleidt
Copy link
Contributor

8.8.2 New property definitions

Example 21 missing SOSA namespace

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants