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

Dear Kerry,

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

This seems like a reasonable and important requirement.
If ever RDFS or OWL axioms do not suffice to achieve proper SSN-full ->
SOSA interoperability, we could design an algorithm to do so otherwise. And
mention in the REC that it should be used to make old SSN instance data
conformant with both the new SSN and SOSA?


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

At least the old terms must be deprecated and asserted to be equivalent to
new terms, isn't it ?


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