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

Hi Rob,

> Equivalence axioms would be required to use the legacy SSN, and these 
> can handle name changes.

Do you mean equivalence relations between old-SSN and new-SSN?

Jano

On 02/07/2017 01:09 PM, Rob Atkinson wrote:
> 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 
> <mailto: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
>     <mailto:kerry.taylor@anu.edu.au>>
>     *Date: *Wednesday, 8 February 2017 at 1:54 am
>     *To: *Rob Atkinson <rob@metalinkage.com.au
>     <mailto:rob@metalinkage.com.au>>, "public-sdw-wg@w3.org
>     <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org
>     <mailto:public-sdw-wg@w3.org>>, "Simon.Cox@csiro.au"
>     <Simon.Cox@csiro.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr
>     <mailto: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 <mailto: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
>     <mailto:rob@metalinkage.com.au>]
>     *Sent:* Tuesday, 7 February 2017 6:07 PM
>     *To:* Armin Haller <armin.haller@anu.edu.au
>     <mailto:armin.haller@anu.edu.au>>; Simon.Cox@csiro.au; Kerry
>     Taylor <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>;
>     janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>;
>     maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>;
>     public-sdw-wg@w3.org <mailto: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
>     <mailto: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 <mailto:Simon.Cox@csiro.au>"
>         <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>
>         *Date: *Tuesday, 7 February 2017 at 1:29 pm
>         *To: *Kerry Taylor <kerry.taylor@anu.edu.au
>         <mailto:kerry.taylor@anu.edu.au>>, Armin Haller
>         <armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>>,
>         "janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>"
>         <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>>,
>         "maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>"
>         <maxime.lefrancois@emse.fr
>         <mailto:maxime.lefrancois@emse.fr>>, "public-sdw-wg@w3.org
>         <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org
>         <mailto: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
>         <mailto:kerry.taylor@anu.edu.au>]
>         *Sent:* Tuesday, 7 February, 2017 12:37
>         *To:* Armin Haller <armin.haller@anu.edu.au
>         <mailto:armin.haller@anu.edu.au>>; janowicz@ucsb.edu
>         <mailto:janowicz@ucsb.edu>; Maxime Lefrançois
>         <maxime.lefrancois@emse.fr
>         <mailto:maxime.lefrancois@emse.fr>>; Cox, Simon (L&W, Clayton)
>         <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>;
>         public-sdw-wg@w3.org <mailto: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 <mailto:janowicz@ucsb.edu>; Maxime
>         Lefrançois <maxime.lefrancois@emse.fr
>         <mailto:maxime.lefrancois@emse.fr>>; Simon.Cox@csiro.au
>         <mailto:Simon.Cox@csiro.au>; Kerry Taylor
>         <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>;
>         public-sdw-wg@w3.org <mailto: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
>         <mailto:janowicz@ucsb.edu>>
>         *Reply-To: *"janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>"
>         <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>>
>         *Date: *Tuesday, 7 February 2017 at 11:44 am
>         *To: *Armin Haller <armin.haller@anu.edu.au
>         <mailto:armin.haller@anu.edu.au>>, Maxime Lefrançois
>         <maxime.lefrancois@emse.fr
>         <mailto:maxime.lefrancois@emse.fr>>, "Simon.Cox@csiro.au
>         <mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au
>         <mailto:Simon.Cox@csiro.au>>, Kerry Taylor
>         <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>,
>         "public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>"
>         <public-sdw-wg@w3.org <mailto: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>
>             <mailto:maxime.lefrancois@emse.fr>
>             *Date: *Tuesday, 7 February 2017 at 10:14 am
>             *To: *"Simon.Cox@csiro.au" <mailto:Simon.Cox@csiro.au>
>             <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>,
>             "janowicz@ucsb.edu" <mailto:janowicz@ucsb.edu>
>             <janowicz@ucsb.edu> <mailto:janowicz@ucsb.edu>, Kerry
>             Taylor <kerry.taylor@anu.edu.au>
>             <mailto:kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org"
>             <mailto:public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
>             <mailto: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>
>             <mailto: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>
>             <mailto: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
>                 <mailto:maxime.lefrancois@emse.fr>]
>                 *Sent:* Monday, 6 February, 2017 17:55
>                 *To:* janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>;
>                 Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
>                 <mailto:Simon.Cox@csiro.au>; kerry.taylor@anu.edu.au
>                 <mailto:kerry.taylor@anu.edu.au>; public-sdw-wg@w3.org
>                 <mailto: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
>                     <mailto: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]
>                         *Sent:* Monday, 6 February, 2017 00:22
>                         *To:* Kerry Taylor <kerry.taylor@anu.edu.au>
>                         <mailto:kerry.taylor@anu.edu.au>; SDW WG
>                         Public List <public-sdw-wg@w3.org>
>                         <mailto: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
>                         <mailto: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 <tel:+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 <mailto:jano@geog.ucsb.edu>
>
>                     Webpage:http://geog.ucsb.edu/~jano/
>                     <http://geog.ucsb.edu/%7Ejano/>
>
>                     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 <mailto:jano@geog.ucsb.edu>
>
>         Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
>
>         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 22:18:05 UTC