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

Phil  said,
>> 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.

On this point, I claim  that my integration architecture solves this completely. 
https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017



In my proposal  *if there is just one namespace*  you know exactly what semantics apply. As BOTH are simultaneously correct.  That is because the semantics of the core, as defined descriptively , Is totally consistent with the semantics of full ssn, as defined axiomatically. If you want the "extra" semantics  axiomatically (and  also if you want more expressive ways of saying things) then you can import ssn and use some of the terms that are in extended ssn.  If you have some instance data that was defined only via the core module then you can rdfs-reason with it as much as you like , or owl reason with it, and you won't get any problems. Every one of the owl entailments  done with core semantics remains true when you transition to the full semantics as long as your instance data follows the descriptive semantics.

Let's think of a hypothetical  example, say ssn:Acutator and ssn:sensor are in the core module including triples:
Ssn:Actuator rdfs:comment  "An Actuator causes something to happen in the world. This distinguishes an Actuator from a Sensor";
Ssn:Sensor rdfs:comment  "A Sensor causes something to happen in the world. This distinguishes a Sensor from an Actuator ";

Let's say the extended (full) module has  
Owl:Disjointclasses  ssn:Actuator ssnSensor  (excuse my turtle).

Now Say you assert in  your own user  ontology.
:mything  a ssn:Actuator 
:mything a   ssn:Sensor  

This would be a very ugly thing to do ---right? - but the  computational semantics of the core cannot forbid it.
But whether or not you have an import statement, the semantics is violated in BOTH the core and the full.
You have used the  terms incorrectly (descriptively) and indeed you would get into trouble if you use use full ssn semantics. 

However this enables the "validation" role of full ssn as Rob was proposing!

I *think* this is  exactly what vertical modularisation says as defined in our FPWD (long before sosa even saw the light of day), supplemented with some comments to help.
Admittedly, that vertical architecture would also be satisfied by sosa and ssn being entirely independent  (I *think*).

--Kerry




-----Original Message-----
From: Phil Archer [mailto:phila@w3.org] 
Sent: Friday, 3 February 2017 11:27 PM
To: 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>
Subject: 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 Sunday, 5 February 2017 06:21:43 UTC