RE: Proposals (was Re: Architecture of SOSA/SSN integration)

Need to squash this one quickly:


Ø  One minor point - there is not a clean formal O&M ontology, so I beleive the work on alignement has already been done by making SOSA definitions consistent with the O&M text, and that is should be possible to "align" with the ISO-19150 encoded version of the O&M model - not that

There is a formal clean O&M Ontology here:
https://github.com/ISO-TC211/GOM/tree/master/isotc211_GOM_harmonizedOntology/19156/2011

Auto-generated from the UML. It is true that nothing is resolvable at the URIs found in the files.
But the URIs do conform to the rules in ISO 19150-2 so can reasonably used as persistent identifiers.

Please see my response to ACTION-255
https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0173.html


Simon

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Thursday, 2 February, 2017 09:14
To: janowicz@ucsb.edu; Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: Phil Archer <phila@w3.org>; SDW WG Public List <public-sdw-wg@w3.org>; ssimmons@opengeospatial.org; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; Armin Haller <armin.haller@anu.edu.au>
Subject: Re: Proposals (was Re: Architecture of SOSA/SSN integration)


Hi
I just replied to a previous thread about a couple of different ways of doing the SSN part - but I think we all violently agree with the basis of Phil's proposall, and accept that SSN can add some extra stuff as required, provided it doesnt redefine anything already covered in SOSA.

One minor point - there is not a clean formal O&M ontology, so I beleive the work on alignement has already been done by making SOSA definitions consistent with the O&M text, and that is should be possible to "align" with the ISO-19150 encoded version of the O&M model - not that this seems to add value other than providing that consistency of interpretation. So nothing to do and no nasty dependencies for the lightweight SOSA I think.

Rob

On Thu, 2 Feb 2017 at 08:52 Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:
Okay, I see. Sorry for causing the confusion :-). Great that you agree on two namespaces as well!


On 02/01/2017 01:47 PM, Joshua Lieberman wrote:
Jano,

There is nothing more to “get”. I’m agreeing to two namespaces because people will expect it for two different (if related) concept collections.

Josh

On Feb 1, 2017, at 4:03 PM, Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:

I am really sorry Josh but I still don't get it. We would have http://www.w3.org/ns/sosa and http://www.w3.org/ns/ssn<http://www.w3.org/ns/sosa-ssn>. Both of them would resolve to an information resource about each of them in the same way we did for the old-SSN. This also provides a very easy handle to understand whether somebody uses/implies the more generic SOSA class or a version that also adds additional axioms, i.e., the SSN class. A namespace is a very nice way to do this and in line with the dereferencing you mentioned as well as popular services such as prefix.cc<http://prefix.cc>. We are not giving up on anything with having two namespaces, we are just increasing usability.

Jano



On 02/01/2017 12:52 PM, Joshua Lieberman wrote:
The simplest possible meaning here. If a namespace is defined somewhere, such as an ontology document, then people expect to be able to use the namespace definition also as a URL that resolves to information about everything that is defined / identified in that namespace. If we have:

sosa-ssn: http://www.w3.org/ns/sosa-ssn


sosa-ssn:SosaVocabulary
sosa-ssn:SsnOntology

People will still expect to be able to resolve http://www.w3.org/ns/sos-ssn alone and it will need to document or at least point to both constructs. To accommodate this idiosyncratic behavior and still “isolate” SOSA, we’ll need to have separate SOS and SSN namespaces.

—Josh


On Feb 1, 2017, at 3:42 PM, Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:

Hi Josh,


I’m also reluctantly agreeing that we should use two namespaces because a number of people have pointed out that linked data users increasingly expect namespaces to be overloaded with meaning and resolvable to documentation as URL’s in their own right.

Could you explain what you mean here? I am not sure whether I am following your argumentation. For something like a namespace resolver, e.g., http://prefix.cc/ , having two namespaces would be great; see also Phil's follow-up email.

Best,
Jano



On 02/01/2017 12:34 PM, Joshua Lieberman wrote:
Phil,

Thanks for making the proposal. I think that’s where we’ve been converging, that terms are defined informally in SOSA to have the same scope as in SSN, so that they can be reused in SSN. There are not a lot of formal mechanisms to make that distinction clear, however, so we have to use narrative and other tools to indicate character of each term set (SOSA: core vocabulary and SSN: ontology built from core vocabulary adding additional concepts).

I’m also reluctantly agreeing that we should use two namespaces because a number of people have pointed out that linked data users increasingly expect namespaces to be overloaded with meaning and resolvable to documentation as URL’s in their own right.

My preference is for Prop 2A as the term profile is also variously used (most assume it means a Type 1 profile that restricts the scope of the profiled specification).

The most important alignment for both SOSA and SSN from an OGC point of view is with O&M and to SensorML. I hope we can focus on the statements for that to pull this together.

—Josh

On Feb 1, 2017, at 3:12 PM, Phil Archer <phila@w3.org<mailto:phila@w3.org>> wrote:

Thanks for pointing out that there is more to SSN than what's in the mapping table, I should have checked that.

OK, so then I do think the SSN-only terms should be in the ssn namespace, but where a term exists in SOSA, that's the one we use. I don't think that SSN-only terms should be defined in the SOSA namespace. Therefore, my proposals become:

Proposal 1: That where vocabulary terms are defined in the SOSA namespace, no new term should be defined for SSN.

Then:

Proposal 2A: That SSN is characterised as a semantic layer on top of SOSA, with additional terms.

OR

Proposal 2B: That SSN is characterised as a profile of SOSA.

I hope this slight change does not diminish your support Krzysztof.

Phil



On 01/02/2017 18:33, Krzysztof Janowicz wrote:

Dear Phil, all,

Thanks a lot for your thoughts and providing this overview. I would like
to express my *strongest* possible support for your proposal and hope we
can finally move forward and understand that no single solution will
make everybody perfectly happy. What you are proposing is largely in
line with what many of us have been suggesting and working on for
months. Please find detailed comments in line.


I believe the currently published document expresses the consensus
view that SOSA is the semantically light weight core and that SSN is
the semantically richer and more specific ontology.

Yes, exactly. But please let me add a few more important detail here.
SOSA is not only lightweight it also targets a different audience,
namely those that would typically be attracted to schema.org<http://schema.org/>-style
semantic annotations. Hence, SSN can/should "use" (e.g., import
subclass, load, profile, etc. [use whatever term makes you happy here])
SOSA but not the other way around. Consequently, SOSA has to be designed
in a way that it can be used entirely independently of SSN. On the other
hand, SSN really has to use SOSA in some way and here is why: As we
discussed before, SOSA also acts as a interoperability fallback level.
What we do *not* want is that SOSA and SSN users cannot exchange data.
However, and following the current design principles of SOSA, SOSA also
acts as common core of both, and, thus SSN users and SOSA users can
indeed exchange data although they do so on a more abstract level. If
you like object-oriented design/programming, then this idea should sound
familiar as it is underlying interfaces, generics, inheritance, and so
forth, and it has been immensely successful.


It defines a class of Actuation that does not appear in SSN or the
others. Nothing more to say.

Yes, and this is not a problem. Same for Sample. We simply forgot about
this in the old-SSN.



Both SOSA and SSN have an Observation class. In my view,
ssn:Observation should be deleted and SSN users should use
sosa:Observation. Ditto for all classes where any differences can be
ironed out.

Yes, exactly. This is where many of us hope to go and this is what has
been proposed over and over again. Btw, Observation is really the only
critical part here as O&M and old-SSN had a clear difference here. This
is not dramatic, just something that we need to work on. I have some
ideas for this that would also solve our current hasValue problem (I
wrote an email about this some days ago and will report back on results
asap with the hope to receive feedback).


But again, it's the SOSA namespace that wins. If we need to tweak the
SOSA definitions, do it.

Yes!



Then we get to sosa:ObservableProperty and ssn:Property.

Looking at the two definitions, there are differences but they look
very minor to my eyes with sosa:ObservableProperty looking slightly
more general, so, again, I'd delete ssn:Property.

Yes! And keeping in mind that SOSA is more general by design. This also
explains why from a set-theoretic perspective SOSA categories (due to
the lightweight semantics of SOSA classes) are more inclusive than SSN
categories and, in fact, contain them. Please also note that due to the
fact that SOSA has a more lightweight semantics, we need more detailed
human readable class descriptions and this is why we have a bit more
text and examples then we had in the old-SSN. In the old-SSN we also
made some mistakes that we can clean up, nobody is perfect after all.



Only when we get to sosa:Result do we see something different, i.e.
ssn:SensorOutput and ssn:ObservationValue. OK, so here, for me, are
the only classes in the ssn namespace, both of which are subclasses of
sosa:Result.

We need to change how we handle values as this part got lost when we
removed the direct linkage to DUL. I am working on this based on the new
version of the QUDT ontology (http://qudt.org/). This will make sure we
are compatible with a very important and widely used ontology. I will
report back on my results as soon as we have agreed on your proposal.
Otherwise I will have to change everything over and over again.


What's the difference between sosa:hosts and sosa:attachedSystem ? Do
we need both?

SOSA should not have an attachedSystem relation. Do you mean SSN?



Hang on, that's *it*. There is no more.

Agreed. This is why we have always tried to highlight that although we
have different opinions and different proposals, they differ by rather
small pieces. Almost all of us agree that we can adjust/align/integrate
SOSA and SSN without major efforts.



Question: do we really need ssn:SensorOutput and ssn:ObservationValue
or could we live with just sosa:Result?

See above. This problem will go away on its own.


Based on the mapping table, I end up with just *two* classes and *no*
properties in the SSN namespace.

There is more to SSN, namely survival ranges of sensors and so forth.


So we're talking here about SSN essentially adding further semantic
constraints on SOSA, not new terms (except possibly two new classes).

SSN contains more, see above. Deployment is another example. This is not
a problem as these classes and relations do not appear in SOSA. SOSA is
simply not the place where one would go into all the details on how a
sensor is constructed and so on, but SSN allows us to do so.


The SOSA vocabulary (it doesn't have rich enough semantics to be
called an ontology in my view) is deliberately defined with loose
semantics - just enough for everyday applications.

I am fine with calling it a vocabulary but as it has OWL axioms I would
prefer to call it ontology. Again, I am fine with whatever the majority
wants. Maybe 'vocabulary' is even better for our envisioned end users.


We've been arguing about the namespace for the SSN terms. Kerry has
been saying that we don't need another namespace. Reading through the
mapping table, now I see why: personally, I only see one vocabulary.

This is where I would personally disagree as SSN adds substantially more
content (see above) and end users tend to confuse namespaces and use
them for communication. Also note that SSN is a bit of an odd name as we
ended up not really talking a lot about (N)etworks. That said, and while
I would strongly prefer two namespaces for clarity, if we all agree to
go with your suggestion, I will certainly not risk a discussion on
namespaces if everybody else would prefer just one namespace.


6. Alignment to OGC Observations and Measurements

Looks like a pretty straightforward alignment to me. I presume
consideration was given to using O&M terms directly in SOSA? Can they
not be used directly? If not, it looks to me as if SOSA terms could be
declared as sub classes and properties of O&M terms.

Yes and we have Simon Cox on the team so this should really not be a
difficult issue. I hope we can give Simon a more active role here but
this is a separate discussion. O&M is really important if we want
SOSA/new-SSN to be a success story.


What about om-lite and sam-lite?

IMHO, om-lite is a subset of O&M and is already compatible with SOSA. In
fact, Simon posted an alignment between SOSA and om-lite in summer of
2016 on our github.



8. Alignment to DOLCE+DNS Ultralite upper ontology (DUL)

For me this is optional but if there's no harm in including it, go ahead.

This is a problematic point especially with respect to old-SSN and
new-SSN. I can demonstrate why this is problematic in a separate email
but I would strongly suggest we have the DUL alignment as an optional
part. Which should not be confused with me saying that it does not
matter. Also note that the idea of contextualized/scoped/optional axioms
does not exist in W3C OWL.



Proposal 1: That all vocabulary terms are defined in the SOSA namespace.

Proposal 2A: That SSN is characterised as a semantic layer on top of
SOSA.

OR

Proposal 2B: That SSN is characterised as a profile of SOSA.

Personally, I'd vote in favour of 1 and 2B.

I would vote for 1 but this is probably a more difficult discussion.

Dear SSN members, please let us accept Phil's proposal without getting
into little infights, very particular details, changes, endless change
request, and so forth as we did over the past 6+ months. No proposal
will ever make everybody absolutely happy but Phil's proposal comes from
a neutral stance and captures almost all aspects we discussed so many
times and that many of us supported by their votes over and over and
over again. More details remain to be clarified, but let us do this
after we agreed on this general outline.

Jano


On 02/01/2017 08:40 AM, Phil Archer wrote:

Dear all,

I am sorry that I was only able to take part in the first half of the
meeting yesterday.

I've been looking at the mapping table [1] and trying to make some
more sense of what I see and offer how I personally would choose to
proceed. In doing this I admit that I have been too lax, allowing the
task force to continue its work without taking the time to understand
the detail of what was being discussed. This is unhelpful and I bear
some responsibility at least for the current malaise. I offer what
follows as a possible way forward. In doing so, please be sure that I
do not have any special powers. This is not a diktat from W3C, just a
proposal from a WG member.

I believe the currently published document expresses the consensus
view that SOSA is the semantically light weight core and that SSN is
the semantically richer and more specific ontology.

OK, so we start with SOSA.

It defines a class of Actuation that does not appear in SSN or the
others. Nothing more to say.

Both SOSA and SSN have an Observation class. In my view,
ssn:Observation should be deleted and SSN users should use
sosa:Observation. Ditto for all classes where any differences can be
ironed out.

But again, it's the SOSA namespace that wins. If we need to tweak the
SOSA definitions, do it.

Then we get to sosa:ObservableProperty and ssn:Property.

Looking at the two definitions, there are differences but they look
very minor to my eyes with sosa:ObservableProperty looking slightly
more general, so, again, I'd delete ssn:Property.

Only when we get to sosa:Result do we see something different, i.e.
ssn:SensorOutput and ssn:ObservationValue. OK, so here, for me, are
the only classes in the ssn namespace, both of which are subclasses of
sosa:Result.

On to properties.

Using the same logic, I would delete:

ssn:featureOfInterest
ssn:observationResult
ssn:observes
ssn:observedProperty
ssn:sensingMethodUsed
ssn:madeObservation (and move ssn:observedBy to the sosa namespace to
be consistent with the other inverse properties)
ssn:onPlatform
ssn:observationSamplingTime
ssn:observationResultTime

What's the difference between sosa:hosts and sosa:attachedSystem ? Do
we need both?

Hang on, that's *it*. There is no more.

Based on the mapping table, I end up with just *two* classes and *no*
properties in the SSN namespace.

Question: do we really need ssn:SensorOutput and ssn:ObservationValue
or could we live with just sosa:Result?

So we're talking here about SSN essentially adding further semantic
constraints on SOSA, not new terms (except possibly two new classes).

That's what I call a profile, i.e. a way in which a particular
vocabulary is used, complete with cardinality constraints and more
finely tuned semantics. We can add textual usage notes and
descriptions as well as semantic axioms but I see no new terms to add.

So here's my table of contents for the document:

1. Introduction
2. Developments since the initial 2009 publication of SSN
3. Modularization
4. The SOSA ontology
5. The SSN Semantic Layer
The SOSA vocabulary (it doesn't have rich enough semantics to be
called an ontology in my view) is deliberately defined with loose
semantics - just enough for everyday applications.

Where more precise semantics are needed, such as in @@@use case@@@ and
@@@ use case@@@ an additional layer can be applied. This allows data
encoded using SOSA to be processed using an OWL resoner.

Then define all the semantics you like in a file at /ns/ssn/.

We've been arguing about the namespace for the SSN terms. Kerry has
been saying that we don't need another namespace. Reading through the
mapping table, now I see why: personally, I only see one vocabulary.

6. Alignment to OGC Observations and Measurements

Looks like a pretty straightforward alignment to me. I presume
consideration was given to using O&M terms directly in SOSA? Can they
not be used directly? If not, it looks to me as if SOSA terms could be
declared as sub classes and properties of O&M terms.

I'd say that this can be part of the normative definition of SOSA.

What about om-lite and sam-lite?

Well, they look pretty similar too. Am I right that these are
CSIRO-only ontologies? In which case, I'd say that any alignment is up
to CSIRO to do and publish.

7. Alignment to SSN of the SSN-XG, ssn-ssnx.

I'd include those assertions in a sub chapter of the one on SSN.

8. Alignment to DOLCE+DNS Ultralite upper ontology (DUL)

For me this is optional but if there's no harm in including it, go ahead.

I am feeling very guilty. I should have looked at that mapping table
before now. I think I have learned a lesson.

Proposal 1: That all vocabulary terms are defined in the SOSA namespace.

Proposal 2A: That SSN is characterised as a semantic layer on top of
SOSA.

OR

Proposal 2B: That SSN is characterised as a profile of SOSA.

Personally, I'd vote in favour of 1 and 2B.

Phil


[1] https://www.w3.org/2015/spatial/wiki/Mapping_Table


On 31/01/2017 23:39, Armin Haller wrote:

Hi,

Herewith I am trying to summarise what has been discussed in today’s
meeting, what was discussed and proposed on the list and what we have
already decided on earlier in the working group:


·         SOSA and SSN use Slash URIs/IRIs

·         SOSA and SSN use different IRIs and are serialised in
separate ontology files (everyone expect Kerry agreed on that one,
although there is her proposal on the wiki stating the same:
https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017)


·         SOSA and SSN may use different ontology namespaces

·         SOSA uses simple semantics as decided upon earlier (i.e.
owl classes, datatype and object properties, inverse properties, but
no domain/range and no other owl restrictions)

·         SSN imports SOS