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

Hmm.
What's happened here is that work using O&M subsequent to its publication six years ago (as an ISO spec) has refined our understanding.

(a)   There are a number of places where we have found the original names left some ambiguity in the eyes of users, and that slight tweaks to the naming might help.

(b)   Also, the O&M model depended on some abstract wild-card classes - in particular GFI_Feature and GF_PropertyType - which were really too general for the purpose, so we are defining more specialized classes here.

(c)    And finally, the style in the ISO UML models is generally not to call properties 'hasXXX' etc, while I observe that this is more common in OWL and RDF.

So from the perspective of 2016/17 we can do one of two things:


(i)                 Persist with the old local names

(ii)               Take the opportunity of a new namespace (which is happening with the move to w3.org regardless of the outcome of the SOSA/SSN discussion) to also have a refresh of the local-names.

I was inclined to take the opportunity for improvement. Hence

-          FeatureOfInterest instead of GFI_Feature - being the subset of features which have observations made on them

-          ObservableProperty instead of GF_Property - being the subset of properties whose values may be estimated by observation/sensing processes (which is distinct from the subset whose values are determined other ways, such as by assertion or inheritance)

-          hasResult instead of result, hasFeatureOfInterest instead of featureOfInterest, isSampleOf instead of sampledFeature etc are all more clear in my opinion.

(I've used the original UML names here as I know them best - Kerry has noted that the SSN names are generally well aligned.)

Naming classes (or properties) is always a bit arbitrary, and should be subordinate to explicit and accurate descriptions, definitions and axiomatizations. But it is often the only thing that users read. Since our stated aim with SOSA was to reach out to a broader audience, better naming is probably a good thing. The deciding factor in my decision to go along with some renaming was audience reach.

As I understood it,  backward compatibility with existing SSN applications will be managed through alignment axioms. So is there any real reason from that side not to change? This is pretty important in relation to Kerry's argument I think. Kerry appears to want to keep the same local-names even while the full URI is changing anyway with the move from purl.org to w3.org URIs - is that it Kerry, or is there something else I haven't followed?

And to complete the circle in terms of the alignment with the O&M standard terminology, there is a scheduled revision of ISO O&M this year, so changes based on use experience (including this) can be rolled back into the standard anyway (though the extent of renaming does depend on whether we make it a 'major revision' or only a 'minor revision').

Simon



From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
Sent: Sunday, 5 February, 2017 23:44
To: SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: Proposals (was Re: Architecture of SOSA/SSN integration) : issue-87 only


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