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
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net