Re: Voting on a name for ssn this week in plenary

Rob makes an excellent point, I'm concerned that we are once again far from
concensus on this.  Should we cancel the vote ?

Ed

On Tue, 4 Apr 2017, 23:37 Rob Atkinson, <rob@metalinkage.com.au> wrote:

> I am still concerned about the lack of clarity of the relationship of SSN
> to SOSA - is it really nothinh more than SOSA + OWL or does it introduce
> new, specialised terms?
>
> It is, evidently, counterproductive to keep revisiting this without first
> getting a clear statement mutually agreed about whether SSN (as currently
> named) is a fish or a fowl.
>
> If, as currently specified, SSN introduces new terms and narrower
> semantics (and I have yet to see any axiomitisation suggestions that are
> not based on definitions in SSN namespace), then I strongly recommend it
> has a distinct namespace.  Hard to argue against sosa + ssn. So do we need
> sosa-full? If we do, then fine, but lets not confuse it with SSN scope.
>
> If (and its by no means certain it is necessary) SOSA owl axioms need to
> be packaged separately, then we have an implementation of Option 5 similar
> to option 8 (sosa, sosa-full and ssn)  which meets all the criteria people
> have raised, (but without the ability to discover sosa-full without prior
> knowledge - which is no more or less bad than any other approach and not
> affected by naming at all.)
>
> I am very strongly against core/full pattern if the two ontologies have
> different scopes.  Full only makes sense if thats all it is.  Core is
> better, in that it at least implies that it may be a subset.
>
> I think the work that falls out perhaps is to either:
>  1) create a stub for sosa-full and place it as future work to populate it
> with additional constraints (this wont break any usage consistent with the
> sosa definitions!)
>  2) extract and generalise those axioms in SSN that are felt to apply to
> the SOSA definitions, and not narrower sensor semantics.  If you call this
> sosa-full, and park the sensor specific parts in another ontology called
> SSN, then the same pattern emerges.
>
> If we cant explain this to ourselves, what hope is there for a wider
> audience to make sense of it?
>
> rob
>
> On Wed, 5 Apr 2017 at 08:08 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:
>
> Raphael,
> Please make a proposal!
> -Kerry
> -----Original Message-----
> From: Raphaël Troncy [mailto:raphael.troncy@eurecom.fr]
> Sent: Wednesday, 5 April 2017 7:35 AM
> To: Phil Archer <phila@w3.org>; Maxime Lefrançois <
> maxime.lefrancois@emse.fr>; Kerry Taylor <kerry.taylor@anu.edu.au>;
> public-sdw-wg@w3.org
> Cc: Armin Haller <armin.haller@anu.edu.au>; Ed Parsons <
> eparsons@google.com>
> Subject: Re: Voting on a name for ssn this week in plenary
>
> > I think that's a little unfair, Raphaël. The decision to have a common
> > base name was discussed at length at the F2F, during the session set
> > aside for SSN. What that common base name is, and what the prefixes
> > might be, are up for discussion - which is what this thread is about.
> > Kerry is trying to offer a straightforward choice but at this stage,
> > the door is open to alternative suffixes.
>
> I originally understood that only the SSN task members did vote during the
> F2F meeting, my mistake if this was not the case.
>
> Room is open for alternative suffixes or separators, but the window is
> closed regarding the fact that the core module and the extended must be
> sub-string, correct?
>
>    Raphaël
>
> --
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Data Science Department
> 450 route des Chappes, 06410 Biot, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242 <+33%204%2093%2000%2082%2042>
> Fax: +33 (0)4 - 9000 8200 <+33%204%2090%2000%2082%2000>
> Web: http://www.eurecom.fr/~troncy/
>
> --


*Ed Parsons *FRGS
Geospatial Technologist, Google

+44 7825 382263 @edparsons
www.edparsons.com