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

> The SOSA is something new, this has nothing to do with 
SSN being known. We are not taking SSN away in any. That said, the new 
SSN is going to be pretty different from the old SSN so maybe it is good 
to make this very clear in all possible ways we can.

Indeed!  And indeed rather strange for these rather dramatic ideas idea to be introduced into a standards track working group at this point in time.
But this does explain my perplexity  expressed as SOSA emerged and my questions were rebuffed.  A view that SOSA is something entirely new and SSN will be very different is certainly quite  incompatible with a view that  sosa is the simple lightweight core of ssn and  lets fix  and extend a few things in ssn while we are at it (including ensure we respect OGC standards along the way), and address our use cases, and make sure we are following our own BP and our new Time.

If sosa is something new then it does not belong in this WG. It is not in our charter -- and as I understand W3C process, is  not something that the W3C would put into a charter either, because WGs do not develop "new" stuff. This is somewhere in W3C process if I need to dig it up. II do understand that new stuff is not incompatible with OGC process and I wonder whether  our massive misunderstanding  arises fundamentally from our attempt to bring the processes together (which is very much not intended as a complaint about our staff support -- although it may  well be interpreted as a fault of our Chairs).

It also explains why we have such dramatic differences of opinion in this group and why we cannot agree how sosa and ssn play together.  Thankyou enormously Jano for putting this out there.


So.... to suggest a  possible way forward that actually seems achievable:

(1) We look seriously at Maxime's proposal
(2) I expect Maxime's proposal also has dul removed by  remaining as an alignment -- so nothing to revisit there I hope.
(3) We look carefully at the terms that Maxime proposes to go in to the core -- (as they will automatically be integrated with ssn under his scheme) and make changes where we notice things people really want in the core that are not there -- and we make sure we make any  corresponding changes in the non-core.
And not to constrain what Maxime does here -- I would hazard a guess the only  changes we might need  are about Activation, Observation, and Sampling .
And around about 20 unresolved issues on our tracker will be resolved in one stroke! 
(4) What happens to "new" sosa? : -- that gets pursued in the following SDW Activity group  that is proposed  and that is able to publish it as a Note. 

-Kerry


-----Original Message-----
From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu] 
Sent: Friday, 3 February 2017 3:38 AM
To: Maxime Lefrançois <maxime.lefrancois@emse.fr>; 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

Hi Maxime,

> I have been away from the group activities for a while, sorry for this. 

Thanks for jumping in Maxime. That said, it would be great if you could contribute on a regular basis as it is sometimes difficult to keep track of who may or may not weight in on a topic. See my reply to your point 5 why this is so important.

> +1 for SOSA and SSN have two different IRIs

Great. I hope we are all in agreement here. At least nobody has objected so far.

> -1 for SOSA and SSN having the same namespace

Same here. See also Phil's email and the reply from others. The proposal is to have two namespaces. One for SOSA and one for SSN.

> +1 for two or three documents SOSA, SOSA+OWL axioms, SOSA+OWL axioms +
> SSN application profile.

Great. Same here.

> +1 for SOSA and SSN new use seperate ontology files

Great. I hope we are all in agreement here. At least nobody has objected 
so far.

> PROPOSAL: use a single name (SSN), prefix and namespace (@Prefix ssn: 
> <http://www.w3.org/ns/ssn/>, with a slash at the end), set of terms, 
> but 2+ documents, corresponding to 2+ profiles:
>  - a "light" (the vocabulary, code name SOSA),
>  - a "full" (imports the "light", adds some terms and semantics, as 
> backward compatible with the old SSN as possible, putting aside the 
> axioms involving DUL),
>  - a "full + DUL alignment", completely compatible with the old SSN.

I am confused. Isn't this contradicting your -1 on having just one 
namespace?

>  1. Communication-wise, and as a WG member, I would argue that a 
> single namespace and a single name "SSN" demonstrates that the group 
> is unified, whereas 2+ namespaces and 2+ names (SSN and SOSA) 
> demonstrates the group is split in two. This is my impression and 
> could the the impression of other people exterior to the group.

I think this is really a misunderstanding of namespaces. The SDW will 
also use different namespaces and nobody would argue that we are not 
unified simply because TIME and SSN do not share a common namespace.

>  2. Name-wise, as a user of the SSN ontology, I actually expect that 
> the outcome of this group is a simplified SSN. The name "SSN" is known 
> to me. So when I see there is now SOSA *and* SSN, I think the outcome 
> of the group is twice as complex that it was before. This is discouraging.

I absolutely disagree with this statement and I cannot follow your 
argumentation. The SOSA is something new, this has nothing to do with 
SSN being known. We are not taking SSN away in any. That said, the new 
SSN is going to be pretty different from the old SSN so maybe it is good 
to make this very clear in all possible ways we can.

>  5. On a very personnal level, I spent much effort making so that the 
> SEAS ontologies use the SSN terms properly, and are compatible with 
> the SSN ontology. I have been quite discouraged when I saw that new 
> name "SOSA", and all the incompatibilities that seemed to arise with 
> SSN. I was afraid it would ruin my efforts in being compatible with 
> the SSN ontology. The SEAS ontologies are an example of usage of the 
> SSN ontology, and I really hope they will remain compatible with the 
> new SSN.

Maxime. This is where the trouble starts. SOSA and SSN are *not* 
incompatible. Kerry will of course state this over and over again but 
this does not make it true. That said, new-SSN is not the same as 
old-SSN so you may have to revisit your ontology if you want to remain 
compatible with the new SSN which has a new URL as well so your old work 
using the old SSN is *not* damaged in any way.


Jano


On 02/02/2017 03:45 AM, Maxime Lefrançois wrote:
> Dear all,
>
> I have been away from the group activities for a while, sorry for 
> this. The current discussion about modularization is also related to 
> my mails and presentations last September, starting from [1]. I have 
> screened the latest mails, minutes, and arguments regarding SOSA and 
> SSN, and will attempt in this mail to share my personnal opinion with 
> you on these points. First and foremost, I would like to express my 
> votes to the following votes taken during the last telco:
>
> +1 for SOSA and SSN have two different IRIs
> -1 for SOSA and SSN having the same namespace
> +1 for two or three documents SOSA, SOSA+OWL axioms, SOSA+OWL axioms + 
> SSN application profile.
> +1 for SOSA and SSN new use seperate ontology files
> These points correspond to what I thought we agreed during the TPAC 
> meeting.
> SOSA and SSN *need* to have two different IRIs *without fragment*, 
> this is the only way they can be defined in different *ontology files*
>
>
> Then I would like to make the following proposal, I'll give my 
> arguments just below:
>
> PROPOSAL: use a single name (SSN), prefix and namespace (@Prefix ssn: 
> <http://www.w3.org/ns/ssn/>, with a slash at the end), set of terms, 
> but 2+ documents, corresponding to 2+ profiles:
>  - a "light" (the vocabulary, code name SOSA),
>  - a "full" (imports the "light", adds some terms and semantics, as 
> backward compatible with the old SSN as possible, putting aside the 
> axioms involving DUL),
>  - a "full + DUL alignment", completely compatible with the old SSN.
>
> My arguments are the following:
>  1. Communication-wise, and as a WG member, I would argue that a 
> single namespace and a single name "SSN" demonstrates that the group 
> is unified, whereas 2+ namespaces and 2+ names (SSN and SOSA) 
> demonstrates the group is split in two. This is my impression and 
> could the the impression of other people exterior to the group.
>  2. Name-wise, as a user of the SSN ontology, I actually expect that 
> the outcome of this group is a simplified SSN. The name "SSN" is known 
> to me. So when I see there is now SOSA *and* SSN, I think the outcome 
> of the group is twice as complex that it was before. This is discouraging.
>  3. Namespace-wise, as a user of the SSN ontology, I don't want to 
> need to check whether a term uses the ssn prefix or the sosa prefix. 
> Just think of how the OWL vocabulary works for a second. If you use 
> owl:unionOf, then your ontology cannot be in OWL Lite. Yet, there is a 
> single "owl" namespace. Would you have voted in favour of multiple 
> "owl" namespaces such as "owl-lite:", "owl-dl", "owl-full" ? If that 
> was the case, one would need to know the precise prefix for each term 
> in the OWL vocabulary, which is very against usability.
>  4. Experience-wise, as the main developer of the ITEA2 SEAS project 
> ontologies, it was a requirement that every term in the SEAS 
> ontologies be under a single namespace. As a matter of fact, this 
> requirement was strong and coming from industrial partners that 
> implemented the SEAS ontologies. Their justification is that this does 
> actually improves usability.
>  5. On a very personnal level, I spent much effort making so that the 
> SEAS ontologies use the SSN terms properly, and are compatible with 
> the SSN ontology. I have been quite discouraged when I saw that new 
> name "SOSA", and all the incompatibilities that seemed to arise with 
> SSN. I was afraid it would ruin my efforts in being compatible with 
> the SSN ontology. The SEAS ontologies are an example of usage of the 
> SSN ontology, and I really hope they will remain compatible with the 
> new SSN.
>
>
> I would like to point you to the ITEA2 SEAS project deliverable D2.2 
> where the SEAS Knowledge Model is defined [2]. Section 2 in this 
> document justifies the choices that were made regarding 
> modularization, versioning, and metadata. It introduces the concepts 
> at stake here (namespace, URI, ontology document, imports, alignments, 
> etc.), and justifies the technical solution we came up with to expose 
> *multiple ontologies and terms under a unique namespace*. The solution 
> we came up with and the justification is more specifically described 
> in the following sections:
>  2.1 - General requirements
>  2.2 - Modularization and versioning
>  2.4 - Namespace and IRIs
>  2.5 - Reusing existing ontologies
>  2.6 - Solution implemented in the ontologies website
>
>
> If my proposal gets some support, I propose my help here:
> ACTION: Maxime to branch the current HEAD branch, implement his 
> proposal, and issue a pull request for further discussion.
>
>
> [1] - https://lists.w3.org/Archives/Public/public-sdw-wg/2016Sep/0194.html

> [2] - 
> http://www.maxime-lefrancois.info/docs/SEAS-D2_2-SEAS-Knowledge-Model.pdf

>
>
> Kind regards,
> Maxime Lefrançois
> http://maxime-lefrancois.info/



-- 
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

Received on Friday, 3 February 2017 00:26:33 UTC