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

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/