Re: How many cores? - was Re: ssn: lost something?

Thanks Simon

It sounds like what you are working on is much closer to what I was looking
for :-)

I dont think i was proposing a single core really - its just that by
focusing on the one module of the proposed modularisation it may have
sounded like it. AFAICT the other two modules  - sensors, deployments still
exist as viewpoints with relatively neat boundaries.

I would be happier still if the bottom tier was itself split into modules
mirroring the owl-y tier above - representing a true "veritical" modularity
pattern - and if necessary the links between then contained as statements
in additional artefacts.  If this is not practicable there should be a
justification possible in a visualisation of the offending
inter-relationships.  (Simplicity is not a smaller number of pieces, so
much as an obvious relationship between the pieces and a small number of
patterns.  The patterns for module relationships I see are:
1) import and add elements (not sure we need this - but it may be the end
Use Case pattern )
2) import and add semantics (vertical modules)
3) import A,B to add A->B and B<-A relationships without compromising
ability to import just A or just B (aid to horizontal modules)
4) import A,B to create reified alignments X->A, X->B, X.metadata*
(alignment module)
5) import A,B,C... to create a single artefact point of entry for an
application needing multiple modules (e.g. SSN in the layer diagram)

These seem to follow our requirements breakdown - is there a existing
characterisation of such patterns we could leverage? No one has thrown it
out there during discussions - but it seems fairly obvious like Object
Relational Mappings have well known patterns.

Rob




On Fri, 1 Jul 2016 at 16:10 <Simon.Cox@csiro.au> wrote:

> Thanks Rob. Insightful, and challenging, as usual.
>
>
>
> Jumping to the bottom, I think you are suggesting that the Observation
> viewpoint should be the core.
>
> I’m not sure this works, as there are at least three key viewpoints, which
> emphasize different primary concerns
>
> -          Provider/sensor – sensor, platform, sensor network, observed
> property
>
> -          Provider/sampling – site, station, specimen, feature of
> interest
>
> -          Consumer – observed property, result, feature of interest
>
> The first two are not addressed by the O&M Observation schema.
>
> These three cores would correspond approximately to one axis of Jano’s
> vertical/horizontal modularization idea [1].
>
>
>
> As you are probably aware, I created om-lite and sam-lite [2] as a
> strawmen for two cores, with the expectation that there would be a third
> core, dealing with the sensor side.
>
> (Sensors are deliberately and explicitly delegated elsewhere in both O&M
> and om-lite - they both only have a stub/abstract class for the range of
> the procedure property.)
>
> The primary goal in om-lite was a more idiomatic OWL version of O&M than
> following the ISO 19105-2 rules produce [3], also with fewer dependencies
> and thus fewer semantic commitments.  (It is a lot more than “pure RDFS”.)
>
>
>
> Subsequent discussion on the SDWWG lists suggests that there may still be
> too much semantics in om-lite/sam-lite for a core –
>
> -          there are explicit domains and ranges in some places, and lots
> of local (guarded) restrictions, and some properties are declared functional
>
> -          while these ontologies are mostly self-contained, sam-lite has
> a dependency on PROV
>
> -          om-lite includes a taxonomy of specialized observation
> classes, and sam-lite of specialized sampling feature classes.
>
>
>
> schema.org is being suggested as a paradigm for the core, i.e. a flat
> list of classes and properties in a single namespace with few relationships.
>
> Working on this assumption, then if there is a single core, then it should
> do little more than enumerate the key ½ dozen classes, and a comparable
> number of properties corresponding with a bland set of interrelationships,
> with no formal domain/range or restrictions – essentially just “tags”.
>
> In the last day I’ve been working with Armin on a proposal in that
> direction [4].
>
> This takes Jano’s proposal [1] and adds
>
> -          SamplingFeature
>
> -          separate classes for Procedures and Devices
>
> -          Actuator.
>
> Personally I’m not convinced that the latter two belong in the core – I
> think I would move those considerations up into the next layer, but they
> are there for the moment.
>
> This would be the base of a stack something like this (would be better
> arranged in concentric circles, but I don’t have a tool to do that):
>
>
>
>
>
> Note that Armin and I have been struggling to get WebProtege to behave,
> and are not convinced it is the long term solution L
>
>
>
> Finally, a request to everyone – **please include links to the things you
> are discussing or complaining about** .
>
> It may take a little more of your time when constructing your message, but
> it will save a lot more for everyone else.
>
> And in particular, it helps everyone else come along with you if they can
> just click and see the actual artefact under discussion.
>
>
>
> Simon
>
>
>
> [1] https://www.w3.org/2015/spatial/wiki/SSN_core_modules
>
> [2] http://def.seegrid.csiro.au/ontology/om/om-lite
>
> http://def.seegrid.csiro.au/ontology/om/sam-lite
>
> [3]
> http://www.semantic-web-journal.net/content/ontology-observations-and-sampling-features-alignments-existing-models-0
>
> http://ceur-ws.org/Vol-1063/paper1.pdf
>
> [4]
> http://webprotege.stanford.edu/#Edit:projectId=da9180fc-add3-4b6a-96d0-bf66c52744b7
>
>
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Thursday, 30 June 2016 9:35 PM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; Cox, Simon (L&W, Clayton)
> <Simon.Cox@csiro.au>; public-sdw-wg@w3.org
> *Subject:* Re: ssn: lost something?
>
>
>
> OK - throwing myself as a sacrifice into the teeth of the storm here ...
>
>
>
> I've spent a bit of time looking at the SSN ontology and seeing where the
> "natural joints" appear to be and looked at the whiteboard sketch around
> proposed modularisation....
>
>
>
> If I then think about the Use Case of a set of OGC SensorWeb services
> deployed, and using SSN to provide a metadata layer that would allow
> reasoning about these and how they relate to each other...
>
>
>
> (at this point - if SSN is purely intended as a language for encoding
> results of sensing - not for describing sensing independent of the encoding
> of the results - then read no further and we'll go our separate ways
> without further pain...)
>
>
>
> I get, and endorse the separation of  RealWorld (Stimulus Sensor
> Observation seems an ugly name - but the packaging of concerns seems OK,
> Device and Deployment....  )
>
>
>
> more on the RealWorld module later...
>
>
>
> where things go awry for me is the imports....
>
>
>
> O&M is not going to import this - but an O&M profile that wants to define
> the sensor process in a specfic level of detail may import parts of SSN.
>
> The containing rings are a problem though - you can only import a specific
> named, described, versioned artefact - not a vagure grouping - you'd need
> to name a package even if all it does is contain transitive imports. And
> the user will need it described to know how to use it this way.
>
>
>
> And this leads me to the questions I expect will bring a rain of frogs
> upon my head..
>
>
>
> I think we need to have a much clearer picture of how the modules would
> provide specific functional outcomes. I'm sure others have thought in more
> detail how to do this - and the suggestions below come from the perspective
> of not being able to see into that thinking well enough but wanting to
> support some fairly obvious use cases around deploying existing OGC
> standards with a much improved ability to share details about the sensing
> process.
>
>
>
> IMHO there are several touch points and requirements w.r.t. the O&M space:
>
> 1) there is a pre-existing scope of O&M implemented in existing services,
> and if we want to talk about this body of information with a more powerful
> language (SSN) then we need a first-class mapping to O&M concepts
>
> 2) There is not yet AFAICT a canonical O&M ontology formalised in OWL -
> however there are candidates (?)  IMHO The ISO 19150 approach to encoding
> O&M appears unworkable however. The "modular" model - the vertical modules
> - RDFS, OWL-DL, SKOS etc views are necessary.
>
> 3) SSN has some extended semantics but does not at first glance appear to
> be fundamentally inconsistent with O&M
>
> 4) Users will hate us if there are multiple virtually indistinguishable
> approaches
>
> 5) The RealWorld maps properties of the Feature of Inerest to the sensing
> process... this seems to be where SamplingFeature comes in.
>
>
>
> I would like to plead for an attempt to break the RealWorld module into
> several distinct modules with these characteristics:
>
> 1) O&M -lite - a pure RDFS vocabulary of the definitions used in O&M, as a
> canonical O&M ontology
>
> 2) O&M-sensor (imports O&M lite and any other SSN modules necessary) -
> defines sensor related extensions that allow an O&M instance to be attached
> to SSN details. (this may be quite trivial and only contain the links
> between observation and Sensing, Sensor etc - perhaps characterised as
> subProperties of om:observationProcess?
>
> 3) An alignment module if required mapping SSN1 terms to the new
> equivalents in appropriate namespaces, and defining the necessary imports)
>
> 3) SSN-ObservedFeature (imports O&M lite and a general spatial ontology
> defining a Feature) - that defines properties of a Feature, and
> relationships between a Feature and a SamplingFeature, and the real world
> phenomena being described
>
>
>
> Device and platform modules would provide for device specific details of
> how the phenomenon is measured. Deployment would identify the
> samplingFeature and FoInterest.  SSN-ObservedFeature would provide the link
> between the FeatureOfInterest and how its properties are measured via a
> SamplingFeature.
>
>
>
> Maybe we first need to explore if we can identify a canonical O&M
> vocabulary we can re-use - and if there are fundamental mismatches with SSN
> semantics? If this has been discussed and documented, just add these
> discussions as links in the modularity discussions I've been pointed to and
> I'll try to understand them. I'm assuming the lack of such links means this
> is just the elephant in the room - and step in to wrestle it like a fool.
>
>
>
>
>
> Rob
>
>
>
> u, 30 Jun 2016 at 11:22 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:
>
> No – I was referring to the version of SSN as published with the FPWD, as
> I said: https://www.w3.org/ns/ssn/ . It also corresponds to the ontology
> documentation in the FPWD. Those things appear  to have been dropped
> accidently.
>
>
>
> *From:* Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> *Sent:* Wednesday, 29 June 2016 6:03 PM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; public-sdw-wg@w3.org
> *Subject:* RE: ssn: lost something?
>
>
>
> Are you looking at SANDA in WebProtege?
>
> That is very incomplete yet.
>
>
>
> I still see all the restrictions in the version of SSN here
> http://purl.oclc.org/NET/ssnx/ssn
>
>
>
> Simon
>
>
>
> *From:* Kerry Taylor [mailto:kerry.taylor@anu.edu.au
> <kerry.taylor@anu.edu.au>]
> *Sent:* Tuesday, 28 June 2016 6:16 PM
> *To:* public-sdw-wg@w3.org
> *Subject:* ssn: lost something?
>
>
>
> Joel and I were looking at ssn today in the context of IoT  and we noticed
> that “ssn:Observation” has lost its restrictions for  properties
> “ssn:observationResultTime”, “ssn:qualityOfObservation” and
> “ssn:observationSamplingTime” somewhere in the translation to the FPWD
> form.
>
> Can anyone explain? Have any others gone missing? Is a more thorough check
> warranted?
>
>
>
> --Kerry
>
>