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 Thursday, 2 February 2017 16:38:37 UTC