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

Just to clarify again, ObervableProperty was renamed in SOSA as to make it more meaningful than Property, in particular, in light of programming libraries such as JQuery, RDFlib etc. that would import it and then potentially map it to an object called Property which is highly confusing to a user. I believe I have argued in the initial design of SOSA not to use Property. However, I don’t think we are married to ObservableProperty. A simple rename in either SOSA or SSN and a change in rdfs:comments is sufficient to solve this issue. Which was on the agenda already back on November 15th last year, but we did not make it that far and then got derailed with other issues in subsequent teleconferences.

From: Kerry Taylor <kerry.taylor@anu.edu.au>
Date: Sunday, 5 February 2017 at 11:44 pm
To: SDW WG Public List <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: Sunday, 5 February 2017 at 11:45 pm


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