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

Ø  There is *no* damage in using two namespaces but

Ah, but there is. Indeed damaging consequences.  If  I understand your integration proposal Jano we have ssn:Sensor subclassOf sosa: Sensor.   Is that right?  Are you still holding to the position that ssn:x classes are subclasses of  corresponding sosa:x classes? And if so then that is a statement that must  either be made in in ssn, or  in sosa or else in an “alignment” that  is a third ontology to confuse everyone? And if not,  please what do you propose for the integration between ssn and sosa terms? Can you give us a worked example please?

Or else we have (as Simon  currently proposes) that   Ssn:Sensor owl:equivalentClass sosa:Sensor Which would also need to live somewhere  (and simon has subclass as above for some other concepts anyway).  Taking a very formal view of this, to make that statement  formally  true   (i.e not inconsistent) would also in addition require all the work of my proposal anyway , ie changing both ssn and sosa a lot. https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN . And this works better with one namespace than 2 (clarity of the concepts being the same because they are syntactically the  same) . But it also works with 2 namespaces if necessary.

Just to repeat myself, I would prefer divorce  (ie failure) to  doing ssn:Sensor subclassOf sosa: Sensor. And certainly should we agree they cannot be integrated, then I would totally support the idea of 2 namespaces as a hint that they have nothing to do with each other. E.g. ssn:Sensor and sosa: Sensor are truly independent concepts emerging from the same WD.


Ø  Let's not experiment.

Please, Jano could *you* kindly experiment by laying clear how you see the next steps going? I invite you to spell it out  by expanding the couple of sentences here: https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Proposal_5_made_by_KJanowicz.  And here https://www.w3.org/2015/spatial/wiki/SSN_core_modules

(and could you kindly  link these together on the wiki so they can be found?) Maybe play it out for the Platform concept in  particular would be most helpful, as you have looked closely at it already.  I know that proposal was a long time ago – since then we know we have dropped “horizontal” so we only have “vertical”.  And that proposal actually looks rather more like mine, I think,  with  only one namespace (but without any rdfs:comments) How does that pan out, please?

There are countless variations in between --  some might  be better with one namespace and some better with 2. Can we hold  off this decision until we agree on how they play together?

--Kerry




From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
Sent: Sunday, 5 February 2017 4:09 PM
To: Phil Archer <phila@w3.org>; Maxime Lefrançois <maxime.lefrancois@emse.fr>; 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

In the absence of any import statements in the instance data, if a dataset only uses SOSA, you know it *can* be interpreted without SSN axioms. If a dataset does use SSN terms, without declaring the import, that's a hint that the publisher is using the richer semantics.

+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).

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.

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.

Best,
Jano


On 02/03/2017 04:26 AM, Phil Archer wrote:


On 03/02/2017 11:56, Maxime Lefrançois wrote:

Hi Phil,

So the question is whether they use different namespaces. Personally, I

believe they should.


I would also like to have your opinion on the pertinence of my other
arguments regarding communication and usability.



This makes the distinction clear for anyone looking
at instance data. If instance data only uses SOSA, there's no need to
look at/consider SSN axioms. If there's just one namespace, you won't
know from the instance data whether it was created with or without
knowledge/use of the extra semantics.

Now that's another point. Inference capabilities / entailment regime (as
per SPARQL 1.1). I will try to convince you that again, one namespace would
be preferable than two.

Suppose we use two namespaces sosa: and ssn:. You suggested to delete terms
from ssn that already exist in sosa.  This means there would not exist
ssn:Sensor, but there would be a sosa:Sensor.

Suppose there is a document somewhere with the following content (let's
forget about prefix declarations):

```
ex:mysensor a sosa:Sensor
```

As the consumer of the instance data, how do I know if the publisher wanted
to use the SOSA or the SSN-new entailment regime? ssn:Sensor does not exist
anyways.

The only possibility to make it work is to keep duplicates for every term
in the ssn namespace, and add some note that:

"if a RDF Graph contains sosa terms, then you should use the sosa
semantics. If a RDF Graph contains ssn terms, then you should use the ssn
semantics".

No. That's crazy, although, to my horror, I realise it is the current situation, which is why I hope we publish a new version before the month is out.



--> That brings confusion in the same REC. What happens if some instance
data contain both sosa and ssn terms ? What happens if I want to integrate
instance data containing sosa terms with instance data containing ssn terms
? what happens if I want to extend SSN with additional axioms ? ...


Suppose now we have only one namespace ssn:. My instance data becomes

```
ex:mysensor a ssn:Sensor
```

As the consumer of the instance data, and in the absence of any mention of
a owl:Ontology, then It's completely up to me to use the SOSA or SSN-new
entailment regime. I have no means to know what the publisher had in mind.
That problem is unrelated to SSN, or SDW. In the absence of some
owl:Ontology in the document, I currently cannot know what the entailment
regime shall be.

On the other hand, as the publisher of this instance data, I *can make this
explicit* by adding an OWL ontology that imports SOSA, or SSN-new. I would
serve instead the following documents:

```
ex: a owl:Ontology; owl:imports ssn:Vocabulary .
ex:mysensor a ssn:Sensor
```

or:

```
ex: a owl:Ontology; owl:imports ssn:Ontology .
ex:mysensor a ssn:Sensor
```

I don't see how that's different from finding data that uses

ex: a owl:Ontology; owl:imports sosa:Vocabulary .
ex:mySensor a sosa:Sensor .

in one dataset, and

ex: a owl:Ontology; owl:imports ssn:Ontology.
ex:mySensor a sosa:Sensor.

The latter makes explicit the use of the SSN layer, the former leaves it up to you. Sorry, but I see no advantage in conflating the two namespaces.

In the absence of any import statements in the instance data, if a dataset only uses SOSA, you know it *can* be interpreted without SSN axioms. If a dataset does use SSN terms, without declaring the import, that's a hint that the publisher is using the richer semantics.

Phil



Besides, I think this issue always remains. Anyone on the web could define
and publish an ontology that adds semantics to such ssn terms.  If he then
serves instance data that use ssn terms and his ontology, the
aforementioned method can make explicit the entailment regime to be used.



Kind regards,
Maxime





--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net