W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

Re: SOSA/SSN integration architecture

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Tue, 28 Feb 2017 07:39:24 +0000
Message-ID: <CACfF9Lz40qdFp10w-_XPekG-Bgs=JVuZAOSFVxht_=jPx_b-vg@mail.gmail.com>
To: Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr>, Raphaël Troncy <raphael.troncy@eurecom.fr>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Two namespaces but three files...

Sosa:owl-dl does not need a new namespace.

As we have been discussing an Ontology IRI is not the same as a namespace
IRI - but it may be, and sosa: and ssn: are both namespaces and ontology

sos:owl-dl is an ontology that does not introduce a new namespace - but its
IRI could be made to redirect to sosa: so if someone really wanted to force
the assumption they get the full ontology (because sosa imports sosa:owl-dl)

NB This is like option 5 without new terms, except the import statements
arethe other way around, and no one really ever needs to directly reference
sosa:owl-dl - everyone can quite happily use just sosa:

Thanks for pointing out the cut-and-past error re unify: - have edited it
to be sosa: and clarified the axiomitisation comes from sosa:owl-dl Ontology

Do you think we need to explicitly deal with the namespace vs ontology IRI
expectations up front?


On Tue, 28 Feb 2017, 5:35 PM Armin Haller <armin.haller@anu.edu.au> wrote:

*From: *Rob Atkinson <rob@metalinkage.com.au>
*Date: *Tuesday, 28 February 2017 at 3:33 pm
*To: *Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <
rob@metalinkage.com.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr>,
Raphaël Troncy <raphael.troncy@eurecom.fr>, "public-sdw-wg@w3.org" <

*Subject: *Re: SOSA/SSN integration architecture

i dont think your interpretation of the implications of Option 2 is
correct, or its wording is very misleading

module:Platform owl:equivalentClass unify:Platform ;

   # additional axioms

   rdfs:isDefinedBy unify:SSNLocalName .

I interpret this as "additional axioms" consistent with the definition, not
as a narrower semantics introduced in module:

Ø  Additional axioms here should mean, narrower semantics introduced in the
module, yes. I see that “additional axioms” here has two meanings. Let me
change that, also in some other options.

also  w.r.t. and if you equate Option 7 and 8 then either you need to look
at them closer or they need to be rewritten more clearly.

There seems to be a confusion that Option 8 somehow doesnt support direct
resolution of terms to relevant ontologies - in that you have argued that
Option 2 is superior in this regard, but AFAICT they are both conforming to
that behaviour.

Ø  As per my other email, I don’t understand the mechanics of Option 3 with
only two namespaces.

Please consider the detailed points inline - and if you think your original
analysis holds could you please cite the specific parts of the options that
lead you to your interpretations.

On Tue, 28 Feb 2017 at 15:04 Armin Haller <armin.haller@anu.edu.au> wrote:

See inline comments

have looked through arguments for votes, and its great to have people's
rationale's laid out.  Hopefully people are happy to examine these and
reconsider votes (I know I am happy to do this when I've misinterpreted).

Ø  I am a 0 with most options (apart from the ones in my opinion are a
derivative of another) and can live with any of the options.

so I'd like to dive into the option 5 comments:

Maxime: -1. This is the current de facto implementation and I could live
with it. The big problem of this solution is that in the same REC, terms
sometimes have namespace sosa:, sometimes namespace ssn:. Again, that might
confuse the end user.

*  "-1" is inconsistent with "I could live with it".

* I dont see that the same term ever has two different namespaces - this is
one of the distinguishing factors of this option - it explicitly avoids
that. Its more like option 1, but with a new namespace only for new terms
so no infrastructure tricks required.

Armin: 0. Since terms are just reused in SSN even if the semantics are
refined, it is impossible to access the stronger semantics of a term
directly through its URI. As this is not Linked Data compliant, I see
Option 2 as superior to this one.

* "Linked Data compliant" is a strong statement - and Linked Data makes no
statements at all about its relationship with OWL.

* Option 2 doesnt address the full semantics issue, except by forcing
instances to use ssn (wrtitten as module:) - so it only does it at the
expense of SOSA and SSN instances being different, and it purs burden on
client to negotiate equivalence relationships. Its a far higher burden on
users who dont expect to have to load and negotiate OWL to understand the
data. Option 2 is no more "Linked Data Compliant" because Linked Data is
also silent on how to handle non-unique naming at run time. In fact Option
2 is not Linked Data in that it demands using OWL to get definitions
transitively via equivalences rather than simple links.

* one option would be for sosa to owl:import sosa+owl.ttl  - so non OWL
environments will just ignore this, and OWL ones will access full semantics

Ø  If you are not able to directly access the intended semantics of a Slash
URI term, you are violating Linked Data principles.

I believe this statement is incorrect for two reasons:

1) Can you cite a requirement in the Linked Data principles for the
intended semantics to be in OWL, rather than the (arguably more Linked Data
friendly) SOSA light RDFS form?

2) Semantics are directly accessible using standard client and server
behaviours in Option 8 because sosal.ttl owl:imports sosa-owl-dl.ttl.

You can judge for yourself if this is something you care about.

I guess I care enough to pick the implications apart in detail :-)

Ø  Option 2 does not put any burden on the user. You either use unify (e.g.
SOSA) and get the SOSA semantics or you use the module (e.g. SSN) and get
the SSN semantics.

Again I disagree. Explicitly: if the use finds an ssn:Platform it needs to
dereference ssn.tll and then traverse the equivalence axiom to find this is
a sosa:Platform. otherwise, how do you propose a user is able to ask if A
is a sosa:Platform when it finds the statement A a ssn:Platform ?

Ø  Option 2 is Linked Data compliant as you can access each terms semantics
directly via its URI. I don’t understand what you mean by “to get
definitions transitively via equivalence”? The equivalence relations are
introduced compared to Option 1 to not only reuse terms

I'm afraid I dont understand what "reuse terms" means in this context

and circumvent the issue with being able to access terms directly.

thats the namespace issue,the user accesses two different terms, and then
needs to understand the equivalence relationship

Again, it is a trade-off between just reusing terms and asserting
equivalence to a new term.

There is no need for such a trade-off in Option 8, just define terms once,
and let OWL machinery find OWL-specific formalisms..

Depends what you care more about, but Option 2 does not put a burden on the
user, it does put a couple of extra

as written it implies equivalence relationships for every SOSA term.

equivalence relations in SSN.

I will add another option for this "clean case..." - the more we look at
this problem the more the mixing of concerns (axiomitisation vs extension)
in SSN over-complicates the implementation.


On Mon, 27 Feb 2017 at 23:10 Armin Haller <armin.haller@anu.edu.au> wrote:


In case of Option 2 as in Option 1 I don’t have a strong preference in
terms of values for “unify” or “module”. Logically SOSA may be more
appropriate for “unify”, but I think some group members, because of the
existing brand SSN prefer SSN for “unify”, which I wouldn’t mind either.

Option 2 introduces equivalence relations and allows therefore access to
the more precise definitions of a term through their URI. In Option 6,
which otherwise is very similar, you can’t. For me the trade-off of
introducing a couple of equivalence relations is worth the ability to
access terms directly. I have removed the word “elegant” and detailed why I
prefer Option 2 over 6.



*From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
*Date: *Monday, 27 February 2017 at 10:39 pm

*To: *Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <
rob@metalinkage.com.au>, Raphaël Troncy <raphael.troncy@eurecom.fr>, "
public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
*Subject: *Re: SOSA/SSN integration architecture

Hi Armin, all,

Armin, just in case we vote for option2, could you state your preferences
in terms of values for ''unify'', ''SOSALocalName'', ''SOSALocalName'',

why is it that using namespaces "unify:" and "module:" in option 2 makes it
more elegant than using namespaces "sosa:" and "ssn:" in option 6  to you?

(if you substitute ''unify:'' by ''sosa:'' and ''module:'' by ''ssn:'', you
get very close to option 6)

Kind regards,


Le lun. 27 févr. 2017 à 11:53, Maxime Lefrançois <maxime.lefrancois@emse.fr>
a écrit :

Dear all,

I added a list of high level PROPOSAL proposals, these may help us proceed
by dichotomy among the options.

The table cells contain a high level description of the options, not the

What is it that confuses you? the lines headers? the columns headers? the
terms "declare" and "refines"? something else?

Two of the new options in the table are now detailed as option 6 and option

There is a "vote" section under each of these options for us to express our

Would love option 1 -  Strongly opposed to options 2, 3, 4 - Could live
with options 5, 6, 7

Some of Rob's ideas in former Option are gathered in

Kind regards,


Le lun. 27 févr. 2017 à 07:23, Armin Haller <armin.haller@anu.edu.au> a
écrit :

Thanks Maxime. I have to say the table confuses me a bit, though. Not sure
if it helps others, who don’t necessarily intimately understand the
options. Others?

I have merged Simon’s and Rob’s options and denoted it as Option 5.

I think the page is fairly stable now and we have discussed potential
derivations of each Option. I would ask everyone now to have their opinions
heard in terms of preference. Maybe also mention what Option you can
definitely not live with and what options are acceptable to you as a

*From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
*Date: *Sunday, 26 February 2017 at 10:44 pm
*To: *Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <
rob@metalinkage.com.au>, Raphaël Troncy <raphael.troncy@eurecom.fr>, "
public-sdw-wg@w3.org" <public-sdw-wg@w3.org>

*Subject: *Re: SOSA/SSN integration architecture

Dear all,

I added a section
a table that summarizes several options, including some that are not
detailed in the wiki page.

About Option 5:

To me it's also equivalent to option 2b/3c, but it provides interesting
features that can be propagated to all of the other options. Some

The introductory sentence is misleading:

 - It mentions that it's "same as option 1, except...". Yet, two namespaces
are defined in option 5, whereas only one is defined in option 1. I would
not say option 5 is the "same as option 1" because of this.

 - It says "new terms are introduced into a module-specific namespace". It
appears in the snippets that this "modules-specific namespace" is the ssn:
namespace. I would rephrase this sentence as "New terms are introduced in
the ssn: namespace"

 - It says "any semantic changes to definitions require new terms". It is
also assumed in all of the other options that SSN brings no semantic change
to SOSA terms, but instead precises their semantics. In those cases where
an "equivalence" relation is used between a SOSA term and its duplicate SSN
term, then SSN terms indirectly precise the semantics of the duplicated
SOSA terms.

 - About "Behaviours are consistent with W3C architecture, and will work
best with compliant tools, but are recoverable (i.e. supported by
documentation hints) if tools make loose assumptions.", see my comments

snippet sosa.ttl:

 - it mentions "sosa:Ontology", which is not defined (is it a typo and you
wanted to use ssn:Ontology ?)

 - the rdfs:comment s provides relevant information and could be used in
the other options. I suggest we add this triple along with "rdfs:seeAlso
ssn:Ontology" in sosa.ttl snippets of other options.

snippet ssn.ttl:

 - the rdfs:comment s provides relevant information and could be used in
the other options. I suggest we add this triple in ssn.ttl snippets of
other options.

 - it mentions "unify:Platform" which is not defined in this option (is it
a typo and you wanted to use sosa:Platform ?)

 - rdfs:subClassOf ssn:System ; should either be in all options, or
nowhere. I suggest we delete.

snippets FlibberSensors.ttl and FlobberSensors.ttl

 - I like the definition of Flibber and Flobber in the urban dic :-) are
they commonly used like Foo and Bar ?

 - these snippets are relevant to any of the other options as well. I
suggest either we add them there, or remove altogether .

"And the final mechanism: if you ask for sosa: or sosa:Definitions using
mimetype for OWL, then you get redirected to ssn:Ontology". I suggest we do
not implement this mechanism.

 - as you "303 redirect" to the URL of the SSN ontology, I agree that this
mechanism conforms to the Web architecture principles. i.e., your are not
"200 OK serving" two different RDF Graphs at the same URL.

 - This mechanism may be documented in the spec, but existing Sem Web will
ignore it. In fact, most Sem Web tools accept preferably
application/rdf+xml. This is the case for OWLAPI [1], and is therefore the
case in Protégé. What's worse, any tool that accepts preferably
application/owl+xml will never be able to load SOSA from its IRI. Yet, SOSA
is a perfectly valid OWL DL Ontology, although it has very few axioms.

Kind regards,


[1] - see class DocumentSource.java and its variable REQUESTTYPES,

Le dim. 26 févr. 2017 à 06:36, Armin Haller <armin.haller@anu.edu.au> a
écrit :

I agree that hijacking conveys a negative meaning. Raphaël already
mentioned earlier that he does not want to convey that negative meaning, so
your renaming to “precises” is good.

We could make Option 2b/3c just Option 5. I will wait for Rob’s response,
but as it looks to Simon and me, these two options are the same.

*From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
*Date: *Saturday, 25 February 2017 at 12:30 am
*To: *Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <
armin.haller@anu.edu.au>, Raphaël Troncy <raphael.troncy@eurecom.fr>, "
public-sdw-wg@w3.org" <public-sdw-wg@w3.org>

*Subject: *Re: SOSA/SSN integration architecture

Dear all,

I checked the options 2 to 4 and corrected some inconsistencies with
respect to the URIs of the ontologies. :

 - the URI of the SOSA ontology is once written http://www.w3.org/ns/sosa/,
and once written unify:localname. From this one can infer that ''unify''
equals "sosa", and ''localname'' equals the empty string.

 - the URI of the SSN ontology is also written unify:localname, so it has
 the  same URI as the SOSA ontology.

The object of the rdfs:isDefinedBy is often the ontology where the term is
defined, not the namespace.

I updated the snippets to reflect this. Please tell me if you think

I believe term "hijacking" is not well chosen here. It's conveys a negative
meaning, and does not reflect what is actually happening:

SSN "refines", or "precises" the semantics of some SOSA terms. I changed
hijacking to "precises".

In option 2b/3c, SOSA and SSN are  not in the same namespace, hence I
hardly see why it would  be considered  as a variant of option 2.

I just added some spaces in option 5 to correct the "code" sections.

Kind regards,


Le ven. 24 févr. 2017 à 09:03, Rob Atkinson <rob@metalinkage.com.au> a
écrit :

And the mime type handling is a corner case that only applies to the case
of clients who want owl and gind resources that dont use explicit imports -
ir instead choose to rely on namespace only (if indeed such clients exist)

On Fri, 24 Feb 2017, 6:36 PM Rob Atkinson <rob@metalinkage.com.au> wrote:

No the difference is no neec to subclass sosa terms to ssn equivalents.

Perhaps this makes no difference after owl entailment but it makes a big
difference in that ssn instances are not sosa instances without extra


On Fri, 24 Feb 2017, 4:23 PM Armin Haller <armin.haller@anu.edu.au> wrote:

Now that you have described your option, I don’t see any difference to
Option 3b which itself is a slight variant of Option 2 (reusing of terms
ONLY rather than reintroducing terms within the new namespace).

You define terms in SOSA.

In SSN you import these terms and add axioms.

If the term has not been introduced in SOSA, you define it in the new
module-specific namespace (SSN).

If I interpret this correctly, it is exactly Option 3b with the addition of
the mechanism of handling MIME types.

*From: *Rob Atkinson <rob@metalinkage.com.au>
*Date: *Friday, 24 February 2017 at 1:58 pm
*To: *Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <
armin.haller@anu.edu.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr>,
Raphaël Troncy <raphael.troncy@eurecom.fr>, "public-sdw-wg@w3.org" <

*Subject: *Re: SOSA/SSN integration architecture

Have added option 5 and some clarifications to issue scope (i.e. what does
extended mean)


On Fri, 24 Feb 2017 at 13:13 Rob Atkinson <rob@metalinkage.com.au> wrote:

IMHO My proposal is not an implementation of option 1,  because new terms
in SSN are added to a new namespace, and only axioms 100% compatible to
SOSA are allowed in SSN against SOSA defined terms.

Option 1 seems to be explicitly about the opposite strategy: new terms in
SSN in the SOSA namespace and heroics in the infrastructure to manage
finding these.

I'm convinced its different, and simpler than the existing options and will
add it - we can always remove it if people can prove one of the other cases
is equivalent,


On Fri, 24 Feb 2017 at 10:38 Armin Haller <armin.haller@anu.edu.au> wrote:


I have removed the **bold** in the implication of Option 1. I do want to
keep the implications neutral. Some people may care a lot about that
specific implication, some others not.

I also deleted the statement “always the case with slash-based URIs” with
the “One needs to dereference a term to figure out where this term is
defined”. Raphaël added the yesterday as an implication. The commonly
expected behaviour/expectation with Ontology Slash URIs on the Linked Data
Web is that the ontology sits at the directory level of that term. I think
it is a valid point to make in this option that the behaviour here and in
Option 2 would be different. Again, some people may care about that, some
others not.

*From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
*Date: *Friday, 24 February 2017 at 6:09 am
*To: *Raphaël Troncy <raphael.troncy@eurecom.fr>, Armin Haller <
armin.haller@anu.edu.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>

*Subject: *Re: SOSA/SSN integration architecture

Dear all,

I updated option 1, and highlighted its multiple variants,

I would like to highlight variant sosa1, for which looking up the unified
namespace leads to the SOSA ontology.

Kind regards,


Le jeu. 23 févr. 2017 à 12:12, Raphaël Troncy <raphael.troncy@eurecom.fr> a
écrit :

> ➢ Done, changed it on the Wiki. I think that makes it clearer.


> ➢ You can use the ontology URI to figure out which terms are in the core
(SOSA). It is the same behaviour as in Option 1. In Option 1 you also
either need to dereference each term to figure out where it is defined or
to use the ontology URI of SOSA or SSN explicitly. If you think this is an
important caveat, you can spell that out in the implication for both

I agree, this is true for both options 1 and 2. Done, I have added for
each: "* One needs to dereference a term to figure out where this term
is defined OR to use the ontology URI of SOSA or SSN explicitly since
there is just ONE unify namespace."

Note: Option 3b is still Option 3b and not a variant of Option 1
although it could be.


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 <04%2093%2000%2082%2042>
Fax: +33 (0)4 - 9000 8200 <04%2090%2000%2082%2000>
Web: http://www.eurecom.fr/~troncy/
Received on Tuesday, 28 February 2017 09:26:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:30 UTC