ISSUE-80 Was: State of SSN: arguments in favour of a single name and namespace, proposal, the SEAS example, proposal of action

By the way, and for the record, most of the mails in this thread are
related to ISSUE-80.


Le mar. 7 févr. 2017 à 23:11, Rob Atkinson <rob@metalinkage.com.au> a
écrit :

>
> I think the nub of the issue (and one its imperative we communicate) is
> that any axioms introduced in  SOSA are explicity entailed (i.e. the user
> doesn't need to import SKOS, or OWL or use anything more than RDFS
> reasoning to get the full set of axioms. So IMHO  its OK to use OWL, but
> not OK to expect the user to follow a specific OWL entailment profile.
>
> After that, collapsing the logical layers of modularity into two
> ontologies is acceptable, mainly because SSN becomes quite elegantly small.
> I still think its worth explicitly specifying the roles of the ontology
> artefacts and the entailment profile require to interpret each, as this is
> a design choice we need to constantly check off against, and we keep
> getting snarled up on these questions.
>
> Rob
>
>
> On Tue, 7 Feb 2017 at 10:48 Armin Haller <armin.haller@anu.edu.au> wrote:
>
> Rob, your proposal does look indeed like something we had in the very
> first draft of the modularisation. As Krzysztof mentioned, we have since
> simplified the architecture (and basically removed the horizontal layers)
> and agreed on the type of OWL relations we have in the core, not
> withstanding that we can add others, if needed. There was consensus in the
> group that the inverseOf is helpful for the end-user to understand the
> relationship between properties, even if an RDFS reasoning regime would
> ignore them. We cannot afford to unravel these decisions again in light of
> our deadlines for the work and the number of other outstanding issues.
>
>
>
> *From: *Krzysztof Janowicz <janowicz@ucsb.edu>
> *Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
> *Date: *Tuesday, 7 February 2017 at 9:58 am
> *To: *Rob Atkinson <rob@metalinkage.com.au>, "Le Phuoc, Danh" <
> danh.lephuoc@tu-berlin.de>, Kerry Taylor <kerry.taylor@anu.edu.au>,
> Maxime Lefrançois <maxime.lefrancois@emse.fr>, Phil Archer <phila@w3.org>,
> 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
>
>
>
> Yes, but since then we voted an having inverse-properties in SOSA and so
> forth. The point is rather that the triple store provider sets the
> reasoning-profile. We should not try to somehow anticipate or enforce this.
>
>
> 1) SOSA definitions
>
> 2) OWL axioms for reasoining over SOSA definitions
>
> 3) SSN definitions refining (new narrower subClass/Property) or adding to
> SOSA defs
>
> 4) SSN OWL axioms
>
>
> I see your point but this is really getting to complex and difficult and
> we also have to keep usability in mind (and also that we only have weeks
> left)
>
> Jano
>
> On 02/06/2017 01:20 PM, Rob Atkinson wrote:
>
> +1 - this is why I keep niggling away at separating the OWL axioms from
> the definitions. IMHO definitions should not require OWL reasoning to
> discover simple RDF axioms.  In fact in the original discussion about
> vertical modularity i would have had horizintal (scope) modules SOSA and
> SSN, and vertical modules (RDFS, OWL) leaviing us with four really simple
> to use ontologies:
>
> 1) SOSA definitions
>
> 2) OWL axioms for reasoining over SOSA definitions
>
> 3) SSN definitions refining (new narrower subClass/Property) or adding to
> SOSA defs
>
> 4) SSN OWL axioms
>
>
>
> I think SSN is likely to be quite small (in extra scope), and meant for a
> more targetted group - and having the OWL in the same ontology is
> practically acceptable - but perhaps its worth keeping them separate simply
> to stop us getting snarled up in interpretation of intentions.
>
>
>
> I guess we could live with SSN including 2,3,4 and being 100% consistent
> with SOSA, so that if you asked for SOSA using the OWL content-type it
> would be acceptable to get the SSN ontology - and if you asked for SSN
> using RDF, JSON etc you could get either the full SSN ontology or the
> sub-graph of RDFS/SKOS definitions.
>
>
>
> (Maybe i'm too focussed on how you would implement applications of such a
> modular ontology - but separation of concerns is just the habit of a
> lifetime :-) )
>
>
>
> Rob
>
>
>
>
>
>
>
> On Tue, 7 Feb 2017 at 06:26 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
>
> Hi Danh,
>
>
>
>
> The point I would like to make is that the ontology can provide  possible
> semantics (RDFS, OWL..), but, we have to take into consideration all
> possible interpretations in data consuming/data annotation phases
> (probably, best practices are needed for each scenarios of use). And don’t
> underestimate the community (Web developers or IoT developers) that assume
>  simple semantics like RDF or RDFS, that’s why schema.org is so success.
> Moreover,  pointing to related Working Group, Web of Things, , there is
> some discussions around how to build just very small code-foot-print
> reasoner to interpret only the data types like the one in Q2 for IoT
> constraint devices.
>
>
>
> Agreed. I think this is a very important discussion and we had it a few
> times before in this group. One key issue here is that there are certain
> things, like the selected reasoning capabilities, that are outside of our
> control. I guess the best way to address this is by providing as much
> detail as possible in the documentation and the ontology to make clear what
> our underlying assumptions were when we created SOSA/SSN.
>
> Jano
>
>
>
>
>
> On 02/06/2017 08:57 AM, Le Phuoc, Danh wrote:
>
> Hi Kerry and Rob, and probably Phil and Maxime in earlier emails on
> semantics &entailment regime for data instances ( I reuse Phil’ “data
> instance term” in previous emails),
>
>
>
> I would like to highlight that the publisher only can provide the
> potential semantics of the ontology or the data annotated with the
> ontologies, then, it’s up to the consumer to choose which semantics they
> would like to interpret the data. For example,
>
>
>
> SOSA uses both RDFS vocabularies and OWL vocabularies (e.g,
> inversedProperty), even it’s very simple but there are some reasoning that
> can be done with this, for example, if you enable only RDFS++ reasoning
> capability[1] to your query engine/SPARQL Endpoint such as Virtuoso or
> AllegroGraph, it can reason over RDFS axioms together “inversed property”
> in following data instance annotation:
>
>
>
> :result1 sosa:isResultOf :observation1;
>
> sosa:hasValue  “true”^^xsd:boolean.
>
>
>
> The RDFS++ reasoning will infer  the implicit triple :  :*observation1
> sosa:hasResult:  :result1*,  therefore, the query engine will be able to
> return 1 result with this query
>
>
>
> *Q1: SELECT * WHERE { ?obs sosa:hasResult ?res}*
>
>
>
> However, if you only use a RDFS reasoner,then,  the reasoner will ignore
> all OWL axioms and treat OWL related triples as regular RDFS statements,
> therefore, the query engine will not return any results with query Q1.
> Along this line, if we have data instances annotated with both SOSA/&SSN
> that have  other strong axioms e.g, owl:Restriction, owl:equivalentClass,
> the RDFS++ reasoner will ignore them and treat them as usual RDFS++
> statements that it  can “understand”, e,g. RDFS vocabulary and
> owl:inverseOf, owl:TranstivePropery.
>
>
>
> On the opposite side of the complexity, the most popular entailment is RDF
> entailment[2] that is default interpretation of data instances annotated
> with RDF-based vocabularies/ontologies. But bear in mind, RDF
> interpretation also does some reasoning even quite trivial, for example in
> bellow Q2 will return 1 result even the data does not explicitly state any
> *“rdf:type”* statement:
>
>
>
> *Q2: SELECT * WHERE { ?obs sosa:hasValue ?value. ?value rdf:type
> xsd:boolean}*
>
>
>
> The point I would like to make is that the ontology can provide  possible
> semantics (RDFS, OWL..), but, we have to take into consideration all
> possible interpretations in data consuming/data annotation phases
> (probably, best practices are needed for each scenarios of use). And don’t
> underestimate the community (Web developers or IoT developers) that assume
>  simple semantics like RDF or RDFS, that’s why schema.org is so success.
> Moreover,  pointing to related Working Group, Web of Things, , there is
> some discussions around how to build just very small code-foot-print
> reasoner to interpret only the data types like the one in Q2 for IoT
> constraint devices.
>
>
>
>
>
> [1]
> http://franz.com/agraph/support/documentation/current/agraph-introduction.html#header3-110
>
> [2] https://www.w3.org/TR/rdf11-mt/#rdf-entailment
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Kerry Taylor <kerry.taylor@anu.edu.au> <kerry.taylor@anu.edu.au>
> *Date: *Monday 6 February 2017 at 04:55
> *To: *Rob Atkinson <rob@metalinkage.com.au> <rob@metalinkage.com.au>,
> Maxime Lefrançois <maxime.lefrancois@emse.fr> <maxime.lefrancois@emse.fr>,
> "janowicz@ucsb.edu" <janowicz@ucsb.edu> <janowicz@ucsb.edu>
> <janowicz@ucsb.edu>, Phil Archer <phila@w3.org> <phila@w3.org>, Armin
> Haller <armin.haller@anu.edu.au> <armin.haller@anu.edu.au>, SDW WG Public
> List <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>, "Cox, Simon (CESRE,
> Kensington)" <Simon.Cox@csiro.au> <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
> *Resent-From: *<public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
> *Resent-Date: *Monday 6 February 2017 at 04:56
>
>
>
> Sorry, I meant by “> Possibly – how would you distinguish these options?
> “ to say that I do not understand what  distinguishes them….
>
> > OWL has its own content type-
>
>
>
> Are you sure?– I don’t know where to look but I can only find this  from
> the old Owl 1.0.:
>
> *2.3 MIME type*
>
> The Web Ontology Working Group has not requested a separate MIME type for
> OWL documents. Instead, we recommend to use the MIME type requested by the
> RDF Core Working Group, namely application/rdf+xml [*RDF Concepts
> <https://www.w3.org/TR/2004/REC-owl-ref-20040210/#ref-rdf-concepts>*], or
> alternatively the XML MIME type application/xml.
>
> As file extension, we recommend to use either .rdf or .owl.
>
> And I can find nothing else owl-specific  here either:
> http://www.iana.org/assignments/media-types/media-types.xhtml
>
>
>
> > Complexity for the provider is preferable to complexity for the
> consumer IMHO.
>
> Always!
>
>
>
> --Kerry
>
>
>
>
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au
> <rob@metalinkage.com.au>]
> *Sent:* Monday, 6 February 2017 12:55 PM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au> <kerry.taylor@anu.edu.au>;
> Rob Atkinson <rob@metalinkage.com.au> <rob@metalinkage.com.au>; Maxime
> Lefrançois <maxime.lefrancois@emse.fr> <maxime.lefrancois@emse.fr>;
> janowicz@ucsb.edu; Phil Archer <phila@w3.org> <phila@w3.org>; Armin
> Haller <armin.haller@anu.edu.au> <armin.haller@anu.edu.au>; SDW WG Public
> List <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>; Cox, Simon (CESRE,
> Kensington) <Simon.Cox@csiro.au> <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
>
>
>
>
>
> 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
>
>
>
>
>
> --
>
> 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
>
>