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

What about if you use sosa namespace, and your instance may (or may not) be
a valid instance of the ssn profile (which also provides some other terms
you may find useful). It is possible to use SSN to enforce, validate,
inference over and discover valid instances of ssn profile.

use SOSA without ssn is simple, but less powerful (and a lower ontological
commitment)

This gets back to my earlier obsession with "what are the modules for"
which I think is re-emerging as the key design driver.

Rob





On Fri, 3 Feb 2017 at 22:56 Maxime Lefrançois <maxime.lefrancois@emse.fr>
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".
>
> --> 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
> ```
>
> 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
>
>