Re: ssn: action-155

A few of specific comments - one trivial, others  fundamental (guess which
is which :-) )
1) inconsistency of spelling modulari(zs)ation
2) There does not seem to be any emphasis on the drivers for modularity
from the consumer's point of view - controlling scope is certainly helpful
for maintenance, but the real benefit comes from allowing the downstream
application to use just the pieces that are relevant, without unnecessary
baggage, Thus there needs to be a design principle that a set of modules
should be designed so that importing a module does not transitively import
unneccessary axioms that may have unintended consequences elsewhere. I'm
sure there is an appropriate formalism for this requirement - but it should
be described in lay language as well IMHO.  Each module should provide
documentation about exactly what it does - what is the interoperability
contract it embodies. (If this is hard to write then probably the module is
not well scoped I suggest). For example, and extended time ontology might
import a basic time ontology, but provide for additional forms of
expression for geological time periods and some new questions to be asked
(above and beyond what the imported time ontology allows).  Modularity
makes documentation a lower burden for both the producer and consumer..
3) The other key aspect of modularity is to allow re-use of external
modules (if they are well-designed as per the point above) and avoidance of
wheel-invention. I suspect there are several patterns here and I'm
encouraged by the substance of the email thread to suggest this ought to be
recognised here - from what I saw the idea is that modules can be "hard"
depdendencies or aligned via "adaptor modules" that conform to some sort of
interface (i.e. an alignement ontology using a particular vocabulary for
that alignment - even if its jsut specifying OWL-DL is required, I think
those expectations are a key part of the modularisation discussion.
4) Obviously the modularity methodology is not scoped to SSN or even
spatial, but to the broader BP discussion - its not unexpected that SSN
being an intrinsically cross-domain and complex concern, which touches on
most data gathering, is going to have to deal with this in the absence of a
well-known and practiced approach.

>From my reading, the points above are not clearly enough expressed, if at
all - and are worth dealing with from a "what does it mean to me"
perspective - which I suggest might boil down to some key principles:
*) Allow elements of SSN to be used with a minimum of transitive imports
*) Test each module for consistency with .imported axioms and against the
target competency questions (IMHO this will drive optimal module scope)
*) Avoid reinventing the wheel (do not define modules unless they offer a
specific function)
*) Define optional (not automatically imported) modules that align SSN with
related ontologies
*) Document the specific purpose of each module (from the perspective of
what you get by importing it) - in lay terms.

I'd take the interesting but fairly in-depth discussion about decidability
and push it to an appendix, and list it as one of the factors influencing
the to-be-defined approach to modularity.

I'm sure others can rephrase these ideas better, but these are very much
what I'm looking for when I look to SSN (or any other ontology) to see if
it is useful in a system context. And I hope to be able to review the
modularity aspect of SSN in such a context.

Hope this helps

Cheers
Rob Atkinson

On Thu, 12 May 2016 at 01:27 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:

> Fully agree with your statement below and this is exactly what I
> envisioned with the figure around modularization that is currently in our
> SSN note. The Sensing Device core is all RDFs based in a schema.org style
> with a very simple mechanism to attach observations. The vertical layers
> then extend that core with more detailed classes and OWL2 axioms,
> eventually reaching the outer layer DUL layering.
>
>
> Great. Intuitively, I think that this all could be done while still
> reusing major parts of the current SSN, i.e., without dramatic changes to
> the existing foundation. I will try to come up with a draft before the
> meeting next week.
>
>
>
>
> On 05/11/2016 12:40 AM, Armin Haller wrote:
>
> Fully agree with your statement below and this is exactly what I
> envisioned with the figure around modularization that is currently in our
> SSN note. The Sensing Device core is all RDFs based in a schema.org style
> with a very simple mechanism to attach observations. The vertical layers
> then extend that core with more detailed classes and OWL2 axioms,
> eventually reaching the outer layer DUL layering.
>
> From: Krzysztof Janowicz <janowicz@ucsb.edu>
> Reply-To: "janowicz@ucsb.edu" <janowicz@ucsb.edu>
> Date: Wednesday, 11 May 2016 6:45 am
> To: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Kerry Taylor <
> kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
> Subject: Re: ssn: action-155
> Resent-From: <public-sdw-wg@w3.org>
> Resent-Date: Wednesday, 11 May 2016 7:47 am
>
> As discussed before, I believe that om-lite should be integrated with the
> current SSN. In fact, I still strongly believe that we need to develop a
> simple core ontology/vocabulary around central notions such as sensor and
> observations that can be used for simple, everyday linked data and acts as
> interfaces/hooks for other SSN modules.
>
> Krzysztof
>
>
> On 05/09/2016 06:06 PM, Simon.Cox@csiro.au wrote:
>
> FWIW All classes and most properties in om-lite have reasonably precise
> definitions in rdf:comment and dct:description properties.  Not formally
> axiomatized, but a lot more than just labels. For example oml:Observation
> is described:
>
>
>
> An observation is an act associated with a discrete time instant or period
> through which a number, term or other symbol is assigned to a phenomenon
> [2]. It involves application of a specified procedure, such as a sensor,
> instrument, algorithm or process chain. The procedure may be applied
> in-situ, remotely, or ex-situ with respect to the sampling location. The
> result of an observation is an estimate of the value of a property of some
> feature. Use of a common model allows observation data using different
> procedures to be combined unambiguously.
>
>
>
> The observation itself is also a feature, since it has properties and
> identity.
>
>
>
> Observation details are important for data discovery and for data quality
> estimation.
>
>
>
> The observation could be considered to carry metadata about an instance of
> a property (of the feature of interest). This property-value metadata
> complements the dataset and feature metadata that have been conventionally
> considered (e.g. ISO 19115).
>
>
>
> The values for the properties 'procedure', 'featureOfInterest',
> 'observedProperty', 'phenomenonTime', 'resultTime' may be inherited from a
> container resource.
>
>
>
> See <http://def.seegrid.csiro.au/ontology/om/om-lite#Observation>
> http://def.seegrid.csiro.au/ontology/om/om-lite#Observation
>
>
>
> Simon
>
>
>
> *From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu <janowicz@ucsb.edu>
> <janowicz@ucsb.edu>]
> *Sent:* Tuesday, 10 May 2016 5:29 AM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au> <kerry.taylor@anu.edu.au>
> <kerry.taylor@anu.edu.au>; public-sdw-wg@w3.org
> *Subject:* Re: ssn: action-155
>
>
>
> Hi Kerry,
>
> Sure. One of the reasons to include DUL in the original SSN was the need
> for a stronger semantic anchoring of the classes and relationships defined
> in SSN. One problem we faced was that terms such as Sensor, System,
> Observation, were under-specific to a degree where a major part of the
> intended interpretation of these classes was encoded in terms of their
> labels. DUL gave us additional axioms to further refine what was meant by
> 'Sensor', 'Observation' and so forth. Removing DUL, will leave us with the
> same problem as we had before, and, thus, I proposed to make use of the
> power of OWL2 to add a stronger axiomatic foundation to SSN (classes).
>
> Best,
> Krzysztof
>
>
>
> On 05/09/2016 05:20 AM, Kerry Taylor wrote:
>
> Krzysztof,
>
> https://www.w3.org/2015/spatial/track/actions/155
>
>
>
>
>
> Could you please address this remark you made in an ssn meeting some time
> ago? I read it as a suggestion for a major ssn rewrite, but perhaps it  is
> a suggestion for an extension instead?  Or something else?  It is sitting
> on this page https://www.w3.org/2015/spatial/wiki/SSN_Tasks  at present
> but maybe it deserves attention as one of these proposals on the wiki here
> https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN?  If
> nothing better can  you please explain it on the list so we can handle it
> appropriately and write it off the “task list” if appropriate?
>
>
>
> Thanks,
>
> Kerry
>
>
>
>
>
>
> --
>
> Krzysztof Janowicz
>
>
>
> Geography Department, University of California, Santa Barbara
>
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
>
>
> Email: jano@geog.ucsb.edu
>
> Webpage: http://geog.ucsb.edu/~jano/
>
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>
>
> --
> Krzysztof Janowicz
>
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
> Email: jano@geog.ucsb.edu
> Webpage: http://geog.ucsb.edu/~jano/
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>
>
> --
> Krzysztof Janowicz
>
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
> Email: jano@geog.ucsb.edu
> Webpage: http://geog.ucsb.edu/~jano/
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>