Re: State of SSN: arguments in favour of a single name and namespace, proposal, the SEAS example, proposal of action

Its just a suggestion - to make two small steps instead of a big
one.Because "core" has no formal accepted meaning and we seem to keep
tripping up over the relationship between SSN and SOSA, because there are
two distinct things happening. Complexity for the provider is preferable to
complexity for the consumer IMHO.

OWL has its own content type- so my reading is we dont need to extend Web
practices to consider serialisation of the SOSA semantics into OWL axioms
as equivalent to the simple RDFS with descriptions, we just get different
resources depending on the serialisation we choose. This enforces and
clarifies the role of the OWL axioms.

I  guess this makes "SSN" a much lighter weight profile with its specific
extended semantics, but thats really not the end of the world.

Rob






On Mon, 6 Feb 2017 at 11:40 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:

> >Are we sometimes confusing "using two namespaces" with "define each
> object in each namespace" ?
>
>
>
> Possibly – how would you distinguish these options? Does the latter
> require an alignment like ssn:Sensor subclassof sosa:Sensor whreas the
> former does not?
>
>
>
> >My concern is whether we should modularise into SOSA, SOSA-OWL and SSN
> extensions to simplify interpretation. SSN can import SOSA-OWL, SOSA-OWL
> can be accessed using content negotiation on the SOSA namespace. IMHO that
> takes one piece of magic knowledge away from the user - how to find SSN
> given SOSA terms, to use OWL reasoning on it.
>
>
>
> I dunno – sounds needlessly complex to me. It seems really strange that an
> ontology  (SSN) needs an intermediary SOSA-OWL to talk to its own core
> (SOSA). Not sure how the content negotiation would work either --- are you
> suggesting that sosa-owl has a different  media type to SOSA? Does that
> really make it easy to find? Or would you use term-by-term redirection like
> Maxime’s model – but that only works if you have some terms that are
> actually different in each module.  And what would SOSA-OWL look like? Does
> this do away with ssn:Sensor subclassof sosa:Sensor ?
>
> -Kerry
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Monday, 6 February 2017 9:31 AM
> *To:* Maxime Lefrançois <maxime.lefrancois@emse.fr>; janowicz@ucsb.edu;
> Phil Archer <phila@w3.org>; Kerry Taylor <kerry.taylor@anu.edu.au>; Armin
> Haller <armin.haller@anu.edu.au>; SDW WG Public List <public-sdw-wg@w3.org>;
> Cox, Simon (CESRE, Kensington) <Simon.Cox@csiro.au>
>
>
> *Subject:* Re: State of SSN: arguments in favour of a single name and
> namespace, proposal, the SEAS example, proposal of action
>
>
>
> Are we sometimes confusing "using two namespaces" with "define each object
> in each namespace" ?
>
>
>
> I think we are fine to have a namespace for SSN, and still use SOSA
> namespace in SSN, and add OWL axioms to reinfoirce SOSA descriptions.
>
>
>
> The distinct SSN namespace allows SSN to introduce addition terms (to
> handle name equivalence, actual subclass specialisations, terms not covered
> in SOSA).
>
>
>
> if we find a sosa: thing in instance data, we should know its consistent
> with SOSA semantics, and if we are fully aware we can use SSN axioms to
> validate it.
>
>
>
> My concern is whether we should modularise into SOSA, SOSA-OWL and SSN
> extensions to simplify interpretation. SSN can import SOSA-OWL, SOSA-OWL
> can be accessed using content negotiation on the SOSA namespace. IMHO that
> takes one piece of magic knowledge away from the user - how to find SSN
> given SOSA terms, to use OWL reasoning on it.
>
>
>
>
>
> Rob
>
>
>
> On Sun, 5 Feb 2017 at 21:58 Maxime Lefrançois <maxime.lefrancois@emse.fr>
> wrote:
>
> Dear Jano,
>
>
>
> +1. And there are other reasons as well, namely the branding for
> instance.  We anticipate a large user base for SOSA (substantially larger
> than (full) SSN). We want SOSA to be a recognizable product and end users
> will assume that they can refer to it by its own namespace, look up the
> namespace at prefix.cc., and so on (see also Josh's argument).
>
>
>
> The argument that could convince me is the one from Simon [1].  I'll add:
> given SSN will import SOSA, then it *will also* talk about actuators and
> sampling. Furthermore, because SSN adds axioms to e.g., sensors, and for
> completeness reasons, I would vote for SSN to include axioms for actuators
> and sampling. Hence I agree that SSN as a name might become too restrictive
> for an ontology where actuators and sampling became so much important.
>
>
>
> So to make it clear, I am still in favor of a single name and namespace. I
> could live with any mention of SSN being renamed "SOSA Full", and:
>
>  - the new ssn namespace being dropped
>
>  - the old ssn namespace redirect to an ontology document that imports
> SSN full and defines alignment with sosa terms.
>
>
>
> Lets follow the KISS principle and do what the vast majority of end users
> would expect. The more we add, the more we have to explain, the more has to
> be maintained, the more can be misunderstood, and so on. Finally, we would
> also all need to fully understand the other proposal, discuss it, compare
> it with current practice, anticipate whether this will be the mainstream
> approach in the future (as we hope SOSA/SSN will be around for many years
> to come), and so on.
>
>
>
> As a user of what will come out of this working group, I must warn you
> that in its current state, SOSA appears to me as arbitrarily incomplete,
> uncoherent, and therefore unuseful. To name but a few that are listed at
> [2]:
>
>  1. there is no relation between feature of interest and observable
> property
>
>  2. links exist between observation/sensor and feature of
> interest/observable property, but there exists no parallel link with
> actuation/actuator and feature of interest/observable property
>
>  3. why is phenomenonTime a object property whereas resultTime is a
> datatype property ? This is counter confusing because they both end with
> "time".
>
>  4. there is the Result for observation/actuation, but there is nothing to
> describe the Command of the actuation.
>
>  5. there is no link between the actuator/sensor and the procedure it
> implements
>
>  6. result time could be replace with prov:generatedAtTime
>
>  7. there is invokedBy/invokes for actuators, but there is only
> madeObservation for sensors
>
>  8. domain of isFeatureOfInterestOf includes only feature of interest, but
> range of inverse property hasFeatureOfInterest includes both feature of
> interest and sample.
>
>  9. actuation and observation are in some "virtual box" one could give a
> proper name to, such as "Procedure execution"
>
>  10. actuator and sensor are in some "virtual box" one could give a proper
> name to, such as "Procedure executor"
>
>  11. to me one should keep sosa:hasResult but delete sosa:Result,
> sosa:resultTime and sosa:hasValue.
>
>
>
> The core modules of the SEAS ontologies are already some kind of
> generalization of SSN and look very similar to SOSA without the
> aforementioned uncoherences. I could also try to push my own solution as
> "the new standard", but I won't. I believe in team work, discussion and
> consensus.
>
>
> If we accept to solve these problems, then I already agreed to update the
> SEAS ontologies so that they are built on top of SOSA. This would
> indirectly make the SEAS implementations become implementations for SOSA
> [3]. Otherwise, I won't be part of the user base.
>
>
> Other proposals for mimicking SSN for actuators exist in the wild, see
> [4]. I believe we want to attract the users base of this ontology too.
>
>
>
>
>
> Let's not experiment. We already agreed on two URLs and two files, let's
> go with two clear namespaces as well and move to the pressing problems we
> need to sort out before we run out of time. These discussions really
> distract us. There is *no* damage in using two namespaces but there is
> clear damage from having an incomplete product by the end of the month.
>
>
>
> I'm not experimenting here. I really hope the work I do can help the group
> move forward by:
>
>
>
>  - having proper turtle documents that, when you look at them, can trigger
> the idea that SOSA and SSN were written by the same group;
>
>  - specifying properly how the w3c server should serve the different
> documents;
>
>  - identifying issues in SOSA and help solving them.
>
>  - being able to do agile modifications to implement right away any
> suggestion so that we discuss on products that are ready to be delivered
> (Agile).
>
>
>
> [1] - https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0051.html
>
> [2] -
> https://github.com/maximelefrancois86/sdw/tree/one-namespace/ssn/one-namespace
>
>
> [3] - http://seas.asema.com/
>
> [4] - http://www.irit.fr/recherches/MELODI/ontologies/SAN#
> <http://www.irit.fr/recherches/MELODI/ontologies/SAN>
>
>
>
> Best,
>
> Maxime
>
>