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

True.

So with respect to ssnx.ttl in the proposal I just made, at line 82 in

https://github.com/w3c/sdw/pull/536/commits/9c3f1cf43d4b22d1b34da630a734608aca02517f

would everyone agree that it should be updated to:

oldssn:Property owl:equivalentClass sosa:ObservableProperty ;

and that ssn:Property which is a new term defined in ssn:  now also
includes actionable properties and non-observable properties ?

Best,
Maxime

Le mar. 7 févr. 2017 à 22:09, Rob Atkinson <rob@metalinkage.com.au> a
écrit :

> NB If the ssn namespace is updated, then the backwards compatibility issue
> here is spurious AFAICT
> Equivalence axioms would be required to use the legacy SSN, and these can
> handle name changes.
>
>
> On Wed, 8 Feb 2017 at 07:48 Armin Haller <armin.haller@anu.edu.au> wrote:
>
> This is a compromise I thought we were heading to yesterday.
>
>
>
> +1 from me for this approach on solving the observable property issue.
>
>
>
> *From: *Kerry Taylor <kerry.taylor@anu.edu.au>
> *Date: *Wednesday, 8 February 2017 at 1:54 am
> *To: *Rob Atkinson <rob@metalinkage.com.au>, "public-sdw-wg@w3.org" <
> public-sdw-wg@w3.org>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Maxime
> Lefrançois <maxime.lefrancois@emse.fr>
> *Subject: *RE: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only: FIRM PROPOSAL
> *Resent-From: *<public-sdw-wg@w3.org>
> *Resent-Date: *Wednesday, 8 February 2017 at 1:55 am
>
>
>
> Rob, Simon,  Armin , Maxime and all,
>
> Don’t get me wrong – I totally agree that ‘a distinction is meaningless”. Given
> (a) the existence of an OGC  standard (O&M) and (b) the long time practice
> in SSN (whcih was only because of (a)) , “Property” really does seem the
> sensible default. And its easier to say!
>
>
>
> However, if indeed ‘Property" was too ambiguous” , and recognising the
> painful double-meaning in RDF, and subject to something sensible happening
> around here for Actuators, and noting that ‘Observable property’ seems to
> be entirely equivalent in meaning to “Property” in anyone’s use of it that
> I can see,
>
> and following up on Armin’s suggestion,
>
>
>
> We could
>
> (1) use Observable property in sosa
>
> (2) use “observable property” in ssn in the restriction context (as in
> sosa) of a property that is the observedproperty of an observation
>
> (3) in ssn assert  observableproperty subclassOf  Property
>
> (4) continue to use Property for all those other things that ssn uses it
> for now, such as the superclass of “survivalrange”.
>
> (5) leave it to a user if they want to assert that those other properties
> (e.g. survival range) are also subclasses of “observableproperty” incase
> they want to observe it
>
> (6) fix rdfs:comments accordingly
>
>
>
>
>
> This  is entirely consistent with my integration proposal  but its is MUCH
> harder  than just sticking to “Property”.
> https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017
> . And it a alows sosa-ssn interoperability perfectly (ie all your
> observational instances still interoperate  both directions). And I can’t
> see the dul alignment being affected.
>
>
>
> Except it is NOT backwardly compatible for ssn users, who use “property”
> for things that are observed. Ideas? Such users could add
> “observableproperty equivalentclass Property” I suppose?  We could put
>  this in ssnx ontology? Is it just much too late at night for me to see if
> there is no problem here anyway – mihgt have to have another look at
> observation to be sure. Maybe its ok without the equivalent assertion…
>
>
>
> Ø  Btw: “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. “
>
> I think that is in direct contradiciotn with our own definitions of
> “observable property’, but I don’t care….see “Assertion’ type below. Surely
> a human sensor can observe the price of an item in a shop? Or the name of a
> person from a nametag? Or the creator of a piece of art by studying its
> style? So can an image processing sensor. Or maybe a barcode scanner.  But
> it is not important.
>
>
>
> Change of topic…
>
> Ø  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?
>
> Lots of reasons. *But the most important one is the bi-directional
> interoperability*. So you can take a ssn full instance , let a reasoner
> run for all the instances, throw away any non-sosa terms and voila you have
> a proper sosa instance. E.g. if you have a sosa:observation  subclass of
> ssn:observation you cannot do this. OTOH you can take a sosa instance,  and
> it is a fully formed ssn instance just start decorating it as it is with
>  any extra ssn properties you want.  E.g. if you have a ssn:observation
>  subclass of sosa:observation you cannot do this.
>
> Ok equivalentclass can do that right —but that ‘s inelegant for other
> reasons.
>
> And its not an “alignment” --- what an ugly design  to make an ontology
> ”align” with its  simple core! Truly bizarre.
>
> And what do we think we are doing to our poor users forcing them to use
> the same term with two different prefixes in the same ontology? Whoever
> would force  that on  anyone???? How are they supposed to know what they
> are to do – even if they actually notice there is a difference before they
> break everything.
>
> I should take on the task of formalising this  property  - I am quite sure
> I did not invent it --- it  is really important to me  or else how can sosa
> make any sense as a core of ssn?– and Jano’s original modularisation
> proposal seems to have this property anyway. Where did it all go wrong?
>
> *So … will you help?* Is there anyone out there that can understand what
> I am saying yet?  Maxime seems to get it!!  I absolutely cannot do this
> alone.
>
>
>
> Kerry
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Tuesday, 7 February 2017 6:07 PM
> *To:* Armin Haller <armin.haller@anu.edu.au>; Simon.Cox@csiro.au; Kerry
> Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu;
> maxime.lefrancois@emse.fr; public-sdw-wg@w3.org
> *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
>
>
>
> 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)
>
> 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
>
>