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

Let's see if your axioms solve the problem:

Some precision first: we may come up with three namespaces. sosa, ssn, and
the old one that already exists, I usually use:
@prefix oldssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
I'll assume that what you meant was: "in alignement we have
Sosa:Property owl:equivalentClass oldssn:Property.


So, suppose there exists doc.ttl with:



<someProp> a oldssn:Property .


and suppose we have the following axiom in sosa or ssn:


Sosa:ObservableProperty rdfs:subClassOf sosa:Property

and suppose we have the following axiom in the document that deprecates the
old ssn terms and aligns them with new sosa/ssn terms

Sosa:Property owl:equivalentClass oldssn:Property.



Then from all this, one can infer a new triple that involves <someProp> and
a term in the sosa namespace:


<someProp> a  sosa:Property .



Your proposal solves our issue. So the question is:


Can we agree on defining both sosa:Property *and* sosa:ObservableProperty
 in SOSA ?


Kind regards,

Maxime





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

> Hi Maxime,
>
>
>
> I’m a bit confused with your example in bellow, but I think following
> axioms might solve the problem without being axiomatically conflicted:
>
>
>
> Sosa:ObservableProperty rdfs:subClassOf sosa:Property
>
>
>
> Then in alignment we have:
>
>
>
> Sosa:Property owl:equivalentClass ssn:Property.
>
>
>
> I’m happy to be corrected here.
>
>
>
> Best,
>
>
>
> Danh
>
>
>
> *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
> *Date: *Tuesday 7 February 2017 at 11:15
> *To: *"Le Phuoc, Danh" <danh.lephuoc@tu-berlin.de>, Rob Atkinson <
> rob@metalinkage.com.au>, Armin Haller <armin.haller@anu.edu.au>,
> "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Kerry Taylor <
> kerry.taylor@anu.edu.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "
> public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
>
>
> *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
>
>
>
> Hi Danh,
>
>
>
> I agree with the fact ssn:Property is quite confusing, and I think that
> was the point Jano made in the first place before changing it.
>
>
>
>
>
> From what I understand, Kerry's point can be reformulated as follows:
>
>
>
> suppose there exists doc.ttl with:
>
>
>
> <someProp> a oldssn:Property .
>
>
>
> and suppose the only axioms we have is:
>
>
>
> sosa:ObservableProperty rdfs:subClassOf oldssn:Property .
>
>
>
> Then one cannot infer a new triple that involves <someProp> and a term in
> the sosa namespace.
>
>
>
>
>
> So. Suppose we keep sosa:ObservableProperty and ssn:Property, and suppose
> we use the following axioms:
>
>
>
> # in the ontology that describes the alignment from the old terms to the
> new terms
>
> oldssn:Property rdfs:subClassOf ssn:Property .
>
> ssn:Property rdfs:subClassOf oldssn:Property .
>
>
>
> # in the new SSN ontology
>
> sosa:ObservableProperty rdfs:subClassOf ssn:Property .
>
>
>
> Then from doc.ttl and using all of these axioms and RDFS reasoning, we can
> infer that:
>
>
>
> <someProp> a ssn:Property .
>
>
>
> That's good. But, we still cannot infer a new triple that involves
> <someProp> and a term in the sosa namespace.
>
>
>
>
>
> The only way to satisfy Kerry's request for bi-directional
> interoperability would be to have one of:
>
>  a) sosa:Property defined in SOSA
>
>  b) ssn:Property rdfs:subClassOf sosa:ObservableProperty . (which we
> agreed is not true)
>
>
>
>
>
> Kind regards,
>
> Maxime
>
>
>
>
>
> Le mar. 7 févr. 2017 à 09:00, Le Phuoc, Danh <danh.lephuoc@tu-berlin.de>
> a écrit :
>
> In opinion, ssn:Property is quite “confusing” property when we introduce
> it to a developer who is new to SSN, as it has the same name of
> rdf:Property and also it’s too generic, “ObservableProperty” seems to be
> “more intuitive” to the not-too-expert in O&M, ontology modelling. However,
> I would agree “backward-compatibility” is very important factor here. So, I
> wonder why not having both with the subclass axiom in SOSA:
>
>
>
> Sosa:ObseverableProperty rdfs:subClassOf sosa:Property.
>
>
>
> As I still think sosa:Property in general enough to capture some
> “properties” as the context/metadata that is “not observed” or “not be able
> to observed” by a sensor”.
>
>
>
> I would love to here the objections to this proposal.
>
>
>
> Best,
>
>
>
>
>
> Danh
>
>
>
> *From: *Rob Atkinson <rob@metalinkage.com.au>
> *Date: *Tuesday 7 February 2017 at 08:07
> *To: *Armin Haller <armin.haller@anu.edu.au>, "Simon.Cox@csiro.au"
> <Simon.Cox@csiro.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, "
> janowicz@ucsb.edu" <janowicz@ucsb.edu>, "maxime.lefrancois@emse.fr" <
> maxime.lefrancois@emse.fr>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
>
>
> *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
> *Resent-From: *<public-sdw-wg@w3.org>
>
> *Resent-Date: *Tuesday 7 February 2017 at 08:08
>
>
>
> FWIW, my experience of people using O&M is that "Property" was too
> ambiguous and people used it in rather arbitrary fashion - strictly is
> should relate to a property of the feature being observed, but with
> intermediate sampling features, and in general the model of the observed
> feature not being available formally this was generally too hard to unravel
> - and people tend to use it as a surrogate for the procedure, or a
> generalised classification of the subject, or just their cat's name or
> something.
>
>
>
> So I would suggest the current long-hand name of "ObservableProperty" is
> helpful - and its an opportunity to educate that "observations" may be
> performed by physical sensors or via models. IMHO there are actually a
> chain of scientific models in play for every physical sensor, and its all
> the same thing and a distinction is meaningless. Sensors are a way to give
> a shorthand identifier to part of such a chain, because the sensor
> construction makes that chain immutable.
>
>
>
> Rob
>
>
>
>
>
>
>
>
>
>
>
> On Tue, 7 Feb 2017 at 13:44 Armin Haller <armin.haller@anu.edu.au> wrote:
>
> Kerry, you seem to be ok with recasting uses of Property in SSN, as below.
> I note here that it does not have to be a recasting of **all**, only
> where appropriate. There are already several other subclasses of Property
> in SSN, e.g. SurvivableProperty, OperatingProperty etc. which seem to be
> introduced in SSN to make it easier for the user of the ontology to know
> what is meant with “Property” in a specific use of the class. The same
> would apply to ObservableProperty that is introduced in the core, making it
> easier for the user to know what this class means, in the absence of OWL
> axioms that give the informed user a clue on its intended use.
>
>
>
>
>
> *From: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au>
> *Date: *Tuesday, 7 February 2017 at 1:29 pm
> *To: *Kerry Taylor <kerry.taylor@anu.edu.au>, Armin Haller <
> armin.haller@anu.edu.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "
> maxime.lefrancois@emse.fr" <maxime.lefrancois@emse.fr>, "
> public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
>
>
> *Subject: *RE: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
>
>
>
> Thanks for exploring this Kerry.
>
>
>
> I agree that at least some ‘derivation’ processes fall into our broad
> definition of ‘sensing’ and ‘observation’.
>
> Note that I did hedge the subclassing with the statement
>
> “These are not necessarily disjoint …”.
>
> But it is clear that some properties definitely are not “observable” in
> any normal sense (e.g. “name”, “owner”, “creator”) and could never be
> associated with sensing procedures or instruments.
>
>
>
> So there is a spectrum, but I would suggest that in the SSN layer at least
> we really are only interested in Observable Properties, and it is likely
> that inventories of these could be usefully assembled, alongside catalogues
> of sensors. And that it is useful to keep these clear of the non-observable
> properties.
>
>
>
> On subclassing: why is it that you dislike having these in alignments? Is
> there a principled reason for this application, or does subclassing
> introduce some general difficulty that I’m not familiar with?
>
>
>
> Simon
>
>
>
> *From:* Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
> *Sent:* Tuesday, 7 February, 2017 12:37
> *To:* Armin Haller <armin.haller@anu.edu.au>; janowicz@ucsb.edu; Maxime
> Lefrançois <maxime.lefrancois@emse.fr>; Cox, Simon (L&W, Clayton)
> <Simon.Cox@csiro.au>; public-sdw-wg@w3.org
> *Subject:* RE: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
>
>
>
> This  subclass means that ssn instance data does not become sosa-compliant
> instance data (I would love to have that if you take all the instances of
> all the core terms out of an ssn full  instance you also have a usable sosa
> instance. I know this is asking a lot… but I want bi-directional
> interoperability which is implied by my proposal for integration. I should
> have spelled this out earlier – and I suppose it needs some formalisation
> to be useful.
>
>
>
> In this case if we really need “ObservableProperty)”  ( and my own view is
> that this is just silly vocabulary, and I’d much rather keep “property” for
> O&M compliance anyway, nevertheless I can live with it)  I would like to
> check again whether **all** SSN uses of Property could be recast as
> “Observable property”.  They are certainly not all  “Observed” properties,
> but given an explanation of what distinguishes “observable” from others
> kind of properties   I would look at the implications.
>
>
>
> OTOH looking at Simon’s ISO list :
>
> >-          Observation
>
> >-          Assertion (e.g. name, price)
>
> >-         Derivation (e.g. classifications based on combinations of
> observed properties)
>
> >-         Inheritance/instantiation (e.g. where a property value is
> assumed on the basis of class membership)
>
> >These are not necessarily disjoint, and it is likely that observable
> properties are the most interesting (depending on you epistemological
> viewpoint) >but it is useful to recognize that observable properties are a
> distinct class.
>
> It is very clear that in sosa we do **not** want “observable properties”
>  because we have sensors that are computational simulations making
> observations by ‘Derivation” so this may not be Observable at all.  And
> surely ours can also can be “Assertion” (in the case the sensor is a human,
> for example). Maybe even inheritance/instantiation too.  For the latter if
> we want to observe that some animal  instance  (such as animals caught in
> my trap) has the property of being a member of some species (e.g. “Homo
> Sapiens” ) on the basis of class membership --Why not? Why should we
> prohibit that property being observed?
>
>
>
> So this is a really strong reason why we should stick to “Property”
> surely! If “Observable property” in this ISO  vocab means anything at all
> then it must be distinc t from  the union  “Property” and so “Property” is
> what we need!
>
>
>
>
>
>
>
> I really  dislike subclass alignments….and I dislike  equivalentclass
> almost  as much, wherever they actually sit. I way prefer using the same
> terms throughout,
>
> Which I tried to show in my proposal.
>
>
>
> Just catching up here so maybe I missed something.
>
>
>
> Thoughts?
>
> -Kerry
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Armin Haller
> *Sent:* Tuesday, 7 February 2017 11:49 AM
> *To:* janowicz@ucsb.edu; Maxime Lefrançois <maxime.lefrancois@emse.fr>;
> Simon.Cox@csiro.au; Kerry Taylor <kerry.taylor@anu.edu.au>;
> public-sdw-wg@w3.org
> *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
>
>
>
> The sub-class relation would only be introduced in SSN not SOSA. I should
> have been more explicit in the second dot-point. The third dot-point means
> to say that.
>
>
>
> *From: *Krzysztof Janowicz <janowicz@ucsb.edu>
> *Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
> *Date: *Tuesday, 7 February 2017 at 11:44 am
> *To: *Armin Haller <armin.haller@anu.edu.au>, Maxime Lefrançois <
> maxime.lefrancois@emse.fr>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>,
> Kerry Taylor <kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org" <
> public-sdw-wg@w3.org>
> *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
>
>
>
> Not sure, whether I am fully understanding this.
>
> -          ObservableProperty is a subclass of ssn:Property
>
>
> This would violate one of our design principles, namely that SOSA does not
> make use of SSN.
>
>
> On 02/06/2017 04:41 PM, Armin Haller wrote:
>
> It looks like we have a proposal here to resolve issue 87:
> https://www.w3.org/2015/spatial/track/issues/87
>
>
>
> Please let me try to restate what was proposed:
>
>
>
> -          ObservableProperty is introduced in SOSA (as is currently
> implemented in: https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl)
>
> -          ObservableProperty is a subclass of ssn:Property
>
> -          ObservableProperty is introduced in SSN as well and the
> subclass relation to ssn:Property is stated within
>
>
>
> That leaves the door open to have another property in SSN (and) SOSA
> concerned with ActuableProperties.
>
>
>
> This should also mean that SSN instances are SOSA instances, since no
> axioms in SOSA are violated.
>
>
>
> Is my understanding correct?
>
>
>
>
>
> *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
> <maxime.lefrancois@emse.fr>
> *Date: *Tuesday, 7 February 2017 at 10:14 am
> *To: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>
> <Simon.Cox@csiro.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>
> <janowicz@ucsb.edu> <janowicz@ucsb.edu>, Kerry Taylor
> <kerry.taylor@anu.edu.au> <kerry.taylor@anu.edu.au>,
> "public-sdw-wg@w3.org" <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
> <public-sdw-wg@w3.org>
> *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
> *Resent-From: * <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
> *Resent-Date: * Tuesday, 7 February 2017 at 10:15 am
>
>
>
> Yes indeed, this is what I meant. Thanks.
>
>
>
> Le lun. 6 févr. 2017 à 23:50, <Simon.Cox@csiro.au> <Simon.Cox@csiro.au> a
> écrit :
>
> Ø  it appears very strange to me to state that a ssn:property is a sub
> property of a sosa:ObservableProperty
>
> Ø  This is what can be read at [1]
>
>
>
> Assuming you mean “it appears very strange to me to state that a
> ssn:Property is a sub class of a sosa:ObservableProperty” then I agree. That
> looks like my error.
>
>
>
> Simon
>
>
>
> *From:* Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr]
> *Sent:* Monday, 6 February, 2017 17:55
> *To:* janowicz@ucsb.edu; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
> <Simon.Cox@csiro.au>; kerry.taylor@anu.edu.au; public-sdw-wg@w3.org
>
>
> *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN integration) :
> issue-87 only
>
>
>
> Ø  And it appears very strange to me to state that an observable property
> is a sub property of a property.
>
> That was a slip of the tongue, I meant:
>
>
>
> it appears very strange to me to state that a ssn:property is a sub
> property of a sosa:ObservableProperty
>
> This is what can be read at [1] and is also what I would model when Phil
> says:
>
> >>> Looking at the two definitions, there are differences but they look
>
>     >>> very minor to my eyes with sosa:ObservableProperty looking slightly
>
>     >>> more general, so, again, I'd delete ssn:Property.
>
>
>
> [1] - https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/ssn-sosa.ttl
>
>
>
> but anyways, +1 in favour of your arguments, and I propose that:
>
>
>
>  - we update sosa-ssn.ttl to reflect what we all agree on;
>
>  - we also consider either to add sosa:ActuableProperty, or roll back to
> just sosa:Property.
>
>
>
> Kind regards,
>
> Maxime
>
>
>
> Not strange actually – not all properties are observable. In the revision
> of ISO 19109:2015 we distinguished between
>
> -          Observation
>
> -          Assertion (e.g. name, price)
>
> -          Derivation (e.g. classifications based on combinations of
> observed properties)
>
> -          Inheritance/instantiation (e.g. where a property value is
> assumed on the basis of class membership)
>
> These are not necessarily disjoint, and it is likely that observable
> properties are the most interesting (depending on you epistemological
> viewpoint) but it is useful to recognize that observable properties are a
> distinct class.
>
>
>
> Yes, not strange at all. I agree with all of Simon's arguments and we also
> made them in one of our telco's half a year ago.
>
>
>
>
> On 02/05/2017 04:57 PM, Simon.Cox@csiro.au wrote:
>
> Ø  And it appears very strange to me to state that an observable property
> is a sub property of a property.
>
>
>
> Not strange actually – not all properties are observable. In the revision
> of ISO 19109:2015 we distinguished between
>
> -          Observation
>
> -          Assertion (e.g. name, price)
>
> -          Derivation (e.g. classifications based on combinations of
> observed properties)
>
> -          Inheritance/instantiation (e.g. where a property value is
> assumed on the basis of class membership)
>
> 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
>
>