Skip to content

Minor clarifications - domain types pattern #494

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.

Sign up for GitHub

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

Open
dr-shorthair wants to merge 6 commits into
base: gh-pages
Choose a base branch
from
Open

Minor clarifications - domain types pattern #494

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
a903d00
Minor clarifications - domain types pattern
dr-shorthair Aug 30, 2026
ee404f4
sub-class --> subclass etc
dr-shorthair Sep 1, 2026
58cd396
Update ssn/chapters/ModelDomainTypes.html
dr-shorthair Sep 1, 2026
d1ea116
Update ssn/chapters/ModelDomainTypes.html
dr-shorthair Sep 1, 2026
4961491
Update ssn/chapters/ModelDomainTypes.html
dr-shorthair Sep 1, 2026
cfdde16
indefinite article
dr-shorthair Sep 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 28 additions & 30 deletions ssn/chapters/ModelDomainTypes.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ <h3>Domain types and FeatureOfInterest</h3>
Actuations, Observations, Samplings, and Deployments can be made on any entity in any context.
For many applications a domain-model has been previously defined.
This will include names and definitions for classes of entities in the domain.
For example: applications in hydrology will refer to types such as water-course, stream, river, reach,
As an example, applications in hydrology might refer to types such as watercourse, stream, river, reach,
storage, aquifer, lake, reservoir, spring, water-table, etc.
</p>
<p>
Expand All @@ -13,13 +13,13 @@ <h3>Domain types and FeatureOfInterest</h3>
When this occurs, the domain entity is the <em>feature of interest</em> of the Execution.
</p>
<p>
Does this therefore require that classes in the domain model are defined as sub-classes of
Does this therefore require that classes in the domain model are defined as subclasses of
<a>sosa:FeatureOfInterest</a>?
No, absolutely not.
RDF and OWL entailments do not work that way.
</p>
<p>
The way the SSN Ontology addresses this is described in the following sub-sections.
The way the SSN Ontology addresses this issue is described in the following subsections.
There are different implications depending on whether you are using the simple
<a href="#sosa-modules">SOSA</a> module, or the more expressive <a href="#ssn-modules">SSN</a> module.
</p>
Expand All @@ -40,24 +40,27 @@ <h4>FeatureOfInterest in SOSA</h4>
</pre>
<p>Note:</p>
<ol>
<li>these have no formal entailments, they are just hints</li>
<li>These have no formal entailments, they are just hints</li>
<li>'Includes' means these types are non-exclusive, so any other type is acceptable, including types from
application-domains</li>
</ol>
<p>
So the 'domain and range' indications in SOSA are functionally harmless.
The fact that
<code class="turtle">sosa:hasFeatureOfInterest schema:rangeIncludes sosa:FeatureOfInterest .</code>
merely says that things of type
<a>sosa:FeatureOfInterest</a> might be found as the object of
hasFeatureOfInterest statements.
No more, no less.
Therefore, the 'domain and range' indications in SOSA are functionally harmless.
The fact that SOSA says
</p>
<pre class="turtle">
sosa:hasFeatureOfInterest schema:rangeIncludes sosa:FeatureOfInterest .
</pre>
<p>
merely says that things of type <a>sosa:FeatureOfInterest</a> <i>might be</i> found as the object of
`hasFeatureOfInterest` statements.
No more, no less.
</p>

<h4>FeatureOfInterest in SSN</h4>
<p>
In SSN there are local (guarded) constraints, which can fix the range of a property
when it appears in the context of a member of a specific class.
<i>when it appears in the context of a member of a specific class</i>.
Related to the <a href="#SOSAFeatureOfInterest">feature of interest</a>, SSN has:
</p>
<pre class="turtle">
Expand All @@ -74,14 +77,13 @@ <h4>FeatureOfInterest in SSN</h4>
owl:allValuesFrom sosa:FeatureOfInterest ] ;
.
</pre>
<p>This says that, in the context of an individual <a>sosa:Execution</a>
or <a>sosa:Deployment</a>,
the object of <a>sosa:hasFeatureOfInterest</a> is always an individual
<a>sosa:FeatureOfInterest</a>.
<p>
This says that, in the context of an individual <a>sosa:Execution</a> or <a>sosa:Deployment</a>, the object of
<a>sosa:hasFeatureOfInterest</a> is always an individual <a>sosa:FeatureOfInterest</a>.
</p>
<p>
However, this does not mean that (i) the object of the statement must be declared to have
`rdf:type sosa:FeatureOfInterest` in advance, or (ii) this is its only type.
However, this does not mean that the object of the statement must be declared to have
`rdf:type sosa:FeatureOfInterest` in advance, nor that this is its only type.
Rather, it means that
</p>
<ul>
Expand All @@ -99,15 +101,12 @@ <h4>FeatureOfInterest in SSN</h4>
then it is automatically inferred to be of type <a>sosa:FeatureOfInterest</a>
<em>in addition to</em> any other information that was already available about it, including any pre-existing type.
</p>
<p><b>This does not require you to derive domain types as sub-classes of
<a>sosa:FeatureOfInterest</a></b>.
It merely says that when a domain individual participates in an Execution (e.g., an Observation)
it becomes a member of the class <a>sosa:FeatureOfInterest</a>
<b>in addition to</b> any pre-existing domain class.
In the context of SSN axiomatization, membership in the class
<a>sosa:FeatureOfInterest</a>
does not need to be asserted explicitly, and does not need to be assigned prior to the involvement of an entity in a
<a>sosa:Execution</a> (or one of its sub-classes) or <a>sosa:Deployment</a>.
<p><b>This does not require the derivation of domain types as subclasses of <a>sosa:FeatureOfInterest</a></b>.
It merely means that when a domain individual participates in an Execution (e.g., an Observation), the individual
becomes a member of the class <a>sosa:FeatureOfInterest</a> <i>in addition to</i> any pre-existing domain class.
In the context of SSN axiomatization, membership in the class <a>sosa:FeatureOfInterest</a> does not need to be
asserted explicitly, and does not need to be assigned prior to the involvement of an entity in a
<a>sosa:Execution</a> (or one of its subclasses) or <a>sosa:Deployment</a>.
</p>
<p>
Consider the following scenario (<a href="#Fig-domain-feature"></a>, <a href="#Fig-domain-feature-observed"></a>).
Expand Down Expand Up @@ -160,9 +159,8 @@ <h4>FeatureOfInterest in SSN</h4>
</p>
<p>
In terms of set theory, the class `hydro:RiverReach` has a non-empty intersection with the class
`sosa:FeatureOfInterest` when a member of `hydro:RiverReach` participates in an
<a>sosa:Observation</a> (or any other subclass of
<a>sosa:Execution</a>).
`sosa:FeatureOfInterest` when a member of `hydro:RiverReach` participates in a
<a>sosa:Observation</a> (or any other subclass of <a>sosa:Execution</a>).
Domain types are not features-of-interest unless they are involved in Executions or Deployments.
The additional typing happens to individual members of the class 'automatically', by entailment, but not to the
domain class as a whole.
Expand Down
Loading