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

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
>

-- 


Phil Archer
Data Strategist, W3C
http://www.w3.org/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Friday, 3 February 2017 12:26:43 UTC