Re: Proposals (was Re: Architecture of SOSA/SSN integration) : issue-87 only from Maxime Lefrançois on 2017-02-07 (public-sdw-wg@w3.org from February 2017)

From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
Date: Tue, 07 Feb 2017 10:15:39 +0000
To: "Le Phuoc, Danh" <danh.lephuoc@tu-berlin.de>, Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <armin.haller@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <CALsPASWOa5i5rrDw0uXnZ=y-Xm8gtq5dSpeEJDn8K1K6O8G-sg@mail.gmail.com>

Hi Danh,

I agree with the fact ssn:Property is quite confusing, and I think that was
the point Jano made in the first place before changing it.

>From what I understand, Kerry's point can be reformulated as follows:

suppose there exists doc.ttl with:

<someProp> a oldssn:Property .

and suppose the only axioms we have is:

sosa:ObservableProperty rdfs:subClassOf oldssn:Property .

Then one cannot infer a new triple that involves <someProp> and a term in
the sosa namespace.

So. Suppose we keep sosa:ObservableProperty and ssn:Property, and suppose
we use the following axioms:

# in the ontology that describes the alignment from the old terms to the
new terms
oldssn:Property rdfs:subClassOf ssn:Property .
ssn:Property rdfs:subClassOf oldssn:Property .

# in the new SSN ontology
sosa:ObservableProperty rdfs:subClassOf ssn:Property .

Then from doc.ttl and using all of these axioms and RDFS reasoning, we can
infer that:

<someProp> a ssn:Property .

That's good. But, we still cannot infer a new triple that involves
<someProp> and a term in the sosa namespace.

The only way to satisfy Kerry's request for bi-directional interoperability
would be to have one of:
a) sosa:Property defined in SOSA
b) ssn:Property rdfs:subClassOf sosa:ObservableProperty . (which we agreed
is not true)

Kind regards,
Maxime

Le mar. 7 févr. 2017 à 09:00, Le Phuoc, Danh <danh.lephuoc@tu-berlin.de> a
écrit :

In opinion, ssn:Property is quite “confusing” property when we introduce it
to a developer who is new to SSN, as it has the same name of rdf:Property
and also it’s too generic, “ObservableProperty” seems to be “more
intuitive” to the not-too-expert in O&M, ontology modelling. However, I
would agree “backward-compatibility” is very important factor here. So, I
wonder why not having both with the subclass axiom in SOSA:

Sosa:ObseverableProperty rdfs:subClassOf sosa:Property.

As I still think sosa:Property in general enough to capture some
“properties” as the context/metadata that is “not observed” or “not be able
to observed” by a sensor”.

I would love to here the objections to this proposal.

Best,

Danh

*From: *Rob Atkinson <rob@metalinkage.com.au>
*Date: *Tuesday 7 February 2017 at 08:07
*To: *Armin Haller <armin.haller@anu.edu.au>, "Simon.Cox@csiro.au"
<Simon.Cox@csiro.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, "
janowicz@ucsb.edu" <janowicz@ucsb.edu>, "maxime.lefrancois@emse.fr" <
maxime.lefrancois@emse.fr>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>

*Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only
*Resent-From: *<public-sdw-wg@w3.org>

*Resent-Date: *Tuesday 7 February 2017 at 08:08

FWIW, my experience of people using O&M is that "Property" was too
ambiguous and people used it in rather arbitrary fashion - strictly is
should relate to a property of the feature being observed, but with
intermediate sampling features, and in general the model of the observed
feature not being available formally this was generally too hard to unravel
- and people tend to use it as a surrogate for the procedure, or a
generalised classification of the subject, or just their cat's name or
something.

So I would suggest the current long-hand name of "ObservableProperty" is
helpful - and its an opportunity to educate that "observations" may be
performed by physical sensors or via models. IMHO there are actually a
chain of scientific models in play for every physical sensor, and its all
the same thing and a distinction is meaningless. Sensors are a way to give
a shorthand identifier to part of such a chain, because the sensor
construction makes that chain immutable.

Rob

On Tue, 7 Feb 2017 at 13:44 Armin Haller <armin.haller@anu.edu.au> wrote:

Kerry, you seem to be ok with recasting uses of Property in SSN, as below.
I note here that it does not have to be a recasting of **all**, only where
appropriate. There are already several other subclasses of Property in SSN,
e.g. SurvivableProperty, OperatingProperty etc. which seem to be introduced
in SSN to make it easier for the user of the ontology to know what is meant
with “Property” in a specific use of the class. The same would apply to
ObservableProperty that is introduced in the core, making it easier for the
user to know what this class means, in the absence of OWL axioms that give
the informed user a clue on its intended use.

*From: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au>
*Date: *Tuesday, 7 February 2017 at 1:29 pm
*To: *Kerry Taylor <kerry.taylor@anu.edu.au>, Armin Haller <
armin.haller@anu.edu.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "
maxime.lefrancois@emse.fr" <maxime.lefrancois@emse.fr>, "
public-sdw-wg@w3.org" <public-sdw-wg@w3.org>

*Subject: *RE: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only

Thanks for exploring this Kerry.

I agree that at least some ‘derivation’ processes fall into our broad
definition of ‘sensing’ and ‘observation’.

Note that I did hedge the subclassing with the statement

“These are not necessarily disjoint …”.

But it is clear that some properties definitely are not “observable” in any
normal sense (e.g. “name”, “owner”, “creator”) and could never be
associated with sensing procedures or instruments.

So there is a spectrum, but I would suggest that in the SSN layer at least
we really are only interested in Observable Properties, and it is likely
that inventories of these could be usefully assembled, alongside catalogues
of sensors. And that it is useful to keep these clear of the non-observable
properties.

On subclassing: why is it that you dislike having these in alignments? Is
there a principled reason for this application, or does subclassing
introduce some general difficulty that I’m not familiar with?

Simon

*From:* Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
*Sent:* Tuesday, 7 February, 2017 12:37
*To:* Armin Haller <armin.haller@anu.edu.au>; janowicz@ucsb.edu; Maxime
Lefrançois <maxime.lefrancois@emse.fr>; Cox, Simon (L&W, Clayton)
<Simon.Cox@csiro.au>; public-sdw-wg@w3.org
*Subject:* RE: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only

This subclass means that ssn instance data does not become sosa-compliant
instance data (I would love to have that if you take all the instances of
all the core terms out of an ssn full instance you also have a usable sosa
instance. I know this is asking a lot… but I want bi-directional
interoperability which is implied by my proposal for integration. I should
have spelled this out earlier – and I suppose it needs some formalisation
to be useful.

In this case if we really need “ObservableProperty)” ( and my own view is
that this is just silly vocabulary, and I’d much rather keep “property” for
O&M compliance anyway, nevertheless I can live with it) I would like to
check again whether **all** SSN uses of Property could be recast as
“Observable property”. They are certainly not all “Observed” properties,
but given an explanation of what distinguishes “observable” from others
kind of properties I would look at the implications.

OTOH looking at Simon’s ISO list :

>- Observation

>- Assertion (e.g. name, price)

>- Derivation (e.g. classifications based on combinations of
observed properties)

>- Inheritance/instantiation (e.g. where a property value is
assumed on the basis of class membership)

>These are not necessarily disjoint, and it is likely that observable
properties are the most interesting (depending on you epistemological
viewpoint) >but it is useful to recognize that observable properties are a
distinct class.

It is very clear that in sosa we do **not** want “observable properties”
because we have sensors that are computational simulations making
observations by ‘Derivation” so this may not be Observable at all. And
surely ours can also can be “Assertion” (in the case the sensor is a human,
for example). Maybe even inheritance/instantiation too. For the latter if
we want to observe that some animal instance (such as animals caught in
my trap) has the property of being a member of some species (e.g. “Homo
Sapiens” ) on the basis of class membership --Why not? Why should we
prohibit that property being observed?

So this is a really strong reason why we should stick to “Property” surely!
If “Observable property” in this ISO vocab means anything at all then it
must be distinc t from the union “Property” and so “Property” is what we
need!

I really dislike subclass alignments….and I dislike equivalentclass
almost as much, wherever they actually sit. I way prefer using the same
terms throughout,

Which I tried to show in my proposal.

Just catching up here so maybe I missed something.

Thoughts?

-Kerry

*From:* Armin Haller
*Sent:* Tuesday, 7 February 2017 11:49 AM
*To:* janowicz@ucsb.edu; Maxime Lefrançois <maxime.lefrancois@emse.fr>;
Simon.Cox@csiro.au; Kerry Taylor <kerry.taylor@anu.edu.au>;
public-sdw-wg@w3.org
*Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only

The sub-class relation would only be introduced in SSN not SOSA. I should
have been more explicit in the second dot-point. The third dot-point means
to say that.

*From: *Krzysztof Janowicz <janowicz@ucsb.edu>
*Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
*Date: *Tuesday, 7 February 2017 at 11:44 am
*To: *Armin Haller <armin.haller@anu.edu.au>, Maxime Lefrançois <
maxime.lefrancois@emse.fr>, "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: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only

Not sure, whether I am fully understanding this.

- ObservableProperty is a subclass of ssn:Property

This would violate one of our design principles, namely that SOSA does not
make use of SSN.

On 02/06/2017 04:41 PM, Armin Haller wrote:

It looks like we have a proposal here to resolve issue 87:
https://www.w3.org/2015/spatial/track/issues/87

Please let me try to restate what was proposed:

- ObservableProperty is introduced in SOSA (as is currently
implemented in: https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl)

- ObservableProperty is a subclass of ssn:Property

- ObservableProperty is introduced in SSN as well and the subclass
relation to ssn:Property is stated within

That leaves the door open to have another property in SSN (and) SOSA
concerned with ActuableProperties.

This should also mean that SSN instances are SOSA instances, since no
axioms in SOSA are violated.

Is my understanding correct?

*From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
<maxime.lefrancois@emse.fr>
*Date: *Tuesday, 7 February 2017 at 10:14 am
*To: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>
<Simon.Cox@csiro.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>
<janowicz@ucsb.edu> <janowicz@ucsb.edu>, Kerry Taylor
<kerry.taylor@anu.edu.au> <kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org"
<public-sdw-wg@w3.org> <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
*Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only
*Resent-From: *<public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
*Resent-Date: *Tuesday, 7 February 2017 at 10:15 am

Yes indeed, this is what I meant. Thanks.

Le lun. 6 févr. 2017 à 23:50, <Simon.Cox@csiro.au> <Simon.Cox@csiro.au> a
écrit :

Ø it appears very strange to me to state that a ssn:property is a sub
property of a sosa:ObservableProperty

Ø This is what can be read at [1]

Assuming you mean “it appears very strange to me to state that a
ssn:Property is a sub class of a sosa:ObservableProperty” then I agree. That
looks like my error.

Simon

*From:* Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr]
*Sent:* Monday, 6 February, 2017 17:55
*To:* janowicz@ucsb.edu; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
<Simon.Cox@csiro.au>; kerry.taylor@anu.edu.au; public-sdw-wg@w3.org

*Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only

Ø And it appears very strange to me to state that an observable property
is a sub property of a property.

That was a slip of the tongue, I meant:

it appears very strange to me to state that a ssn:property is a sub
property of a sosa:ObservableProperty

This is what can be read at [1] and is also what I would model when Phil
says:

>>> 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.

[1] - https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/ssn-sosa.ttl

but anyways, +1 in favour of your arguments, and I propose that:

- we update sosa-ssn.ttl to reflect what we all agree on;

- we also consider either to add sosa:ActuableProperty, or roll back to
just sosa:Property.

Kind regards,

Maxime

Not strange actually – not all properties are observable. In the revision
of ISO 19109:2015 we distinguished between

- Observation

- Assertion (e.g. name, price)

- Derivation (e.g. classifications based on combinations of
observed properties)

- Inheritance/instantiation (e.g. where a property value is
assumed on the basis of class membership)

These are not necessarily disjoint, and it is likely that observable
properties are the most interesting (depending on you epistemological
viewpoint) but it is useful to recognize that observable properties are a
distinct class.

Yes, not strange at all. I agree with all of Simon's arguments and we also
made them in one of our telco's half a year ago.

On 02/05/2017 04:57 PM, Simon.Cox@csiro.au wrote:

Ø And it appears very strange to me to state that an observable property
is a sub property of a property.

Not strange actually – not all properties are observable. In the revision
of ISO 19109:2015 we distinguished between

- Observation

- Assertion (e.g. name, price)

- Derivation (e.g. classifications based on combinations of
observed properties)

- Inheritance/instantiation (e.g. where a property value is
assumed on the basis of class membership)

Simon

*From:* Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr
<maxime.lefrancois@emse.fr>]
*Sent:* Monday, 6 February, 2017 00:22
*To:* Kerry Taylor <kerry.taylor@anu.edu.au> <kerry.taylor@anu.edu.au>; SDW
WG Public List <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
*Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
issue-87 only

+1 for Kerry's arguments.

And it appears very strange to me to state that an observable property is a
sub property of a property.

I just changed to sosa:Property instead of sosa:ObservableProperty in the
proposal I am currently working on.

+ add relations and classes that are missing

best,

Maximle

Le dim. 5 févr. 2017 à 13:44, Kerry Taylor <kerry.taylor@anu.edu.au> a
écrit :

PhilA has said

>>> 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.

This is issue-87. As you can see by my analysis last November in the
tracker https://www.w3.org/2015/spatial/track/issues/87 ,

(1). A sosa: Observable Property is NOT an O&M property. The O&M standard
has no such term.

(2) The ssn:Property has the same intended meaning as an an O&M
Property (and, yes it is an O&M “Property”) and this is explicit by
the annotation within ssn “<dc:source> skos:exactMatch 'property'
[O&M] http://www.opengeospatial.org/standards/om </dc:source>”

(3) What is shown in the mapping table is not the complete annotation for
ssn:Property – just an extract. However that very paragraph deserves
improvement.

(4) ssn:Property is used in other places throughout ssn that have nothing
to do with the narrow context associated with Observation as it is used in
SOSA.

In particular, nothing to do with a

(5) ssn:Property cannot be deleted --- many, many things will break. Nor
can it be replaced by sosa:ObservableProperty (see 4). Maybe it is
possible to say sosa:Property rdfs:SubclassOf ssn:Property but this has
its problems too (ssn instances would not be sosa instances). A more
sophisticated workaround is required if we head that direction.

(6) ssn users know it as “Property” . So do O&M users. Why change, who are
we serving?

(6) OTOH a simple name change in sosa to “Property” and some clarification
on the rdfs:comments in both places would work – and then ssn and sosa can
use the very same term. This is the essence of my proposal on the wiki as a
pattern to solve all these many problems.
https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017

In this case the rdfs:comment suggested by Armin looks very close but I
prefer abbreviated as follows (due to (4) ) “An observable quality of a
real world phenomena (thing, person, event, etc.) “ or here is another idea
that I propose “An observable quality of a real world phenomena (object,
person, or event), typically a FeatureOfInterest” . That works well in
the context for my proposal that also shows how to use it in the simple
core.

-Kerry

Dr Kerry Taylor

Associate Professor (Data Science)

Research School of Computer Science

ANU College of Engineering and Computer Science

Canberra ACT 2601 Australia

+61 2 6125 8560 <+61%202%206125%208560>

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

Received on Tuesday, 7 February 2017 10:16:26 UTC