W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

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

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Tue, 7 Feb 2017 14:22:23 -0800
To: Kerry Taylor <kerry.taylor@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Armin Haller <armin.haller@anu.edu.au>, "rob@metalinkage.com.au" <rob@metalinkage.com.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, "maxime.lefrancois@emse.fr" <maxime.lefrancois@emse.fr>
Message-ID: <b5d33824-ba9c-de9c-a11e-5bea92d8e640@ucsb.edu>
> In ssnx we have an alignment ontology  for backward compatibility 
> whose purpose is to (with a reasoner) turn any old ssn into new ssn so 
> they can play together.   My problem was what goes there.

[Trying to navigate all the many emails]. What you mean with *any* old 
ssn? Data that used the old ssn? Also keep in mind that old ssn creates 
many different assertions compared new ssn, so I am not 100% sure what 
you mean by compatibility.


On 02/07/2017 02:16 PM, Kerry Taylor wrote:
>
> Now I don’t know  what you mean --- sorry – but I note Danh and Maxime 
> seem to have resolved this backward compatibility question in another 
> thread. Maybe there are other ways too.
>
> In ssnx we have an alignment ontology  for backward compatibility 
> whose purpose is to (with a reasoner) turn any old ssn into new ssn so 
> they can play together.   My problem was what goes there.
>
> Kerry
>
> *From:*Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> *Sent:* Wednesday, 8 February 2017 8:09 AM
> *To:* Armin Haller <armin.haller@anu.edu.au>; Kerry Taylor 
> <kerry.taylor@anu.edu.au>; rob@metalinkage.com.au; 
> public-sdw-wg@w3.org; maxime.lefrancois@emse.fr
> *Subject:* RE: Proposals (was Re: Architecture of SOSA/SSN 
> integration) : issue-87 only: FIRM PROPOSAL
>
> Hold on –
>
> ØExcept it is NOT backwardly compatible for ssn users, who use 
> “property” for things that are observed.
>
> Is this still the URI issue, or are we worried about local names, or 
> is it the definitions that you are worried about?
>
> If it is the URIs, then ‘ssn users’ used 
> http://purl.oclc.org/NET/ssnx/ssn#Propertyfor things that are observed.
>
> In the revised vocabularies, it will be
>
> http://www.w3.org/ns/sosa/ObservableProperty and 
> http://www.w3.org/ns/ssn/Property
>
> These are different anyway.
>
> I don’t know that we should worry about local-names.
>
> The definitions (textual and axiomatic) can be dealt with.
>
> Is there something else?
>
> Simon
>
> *From:*Armin Haller [mailto:armin.haller@anu.edu.au]
> *Sent:* Wednesday, 8 February, 2017 07:49
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au 
> <mailto:kerry.taylor@anu.edu.au>>; Rob Atkinson 
> <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>; 
> public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>; Cox, Simon (L&W, 
> Clayton) <Simon.Cox@csiro.au <mailto: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
>
> 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 
> <mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au 
> <mailto: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]
> *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 
> <mailto: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:23:01 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:29 UTC