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

Maxime,
WHAT A BREATH OF FRESH AIR –thank you  so much for weighing in!

And I think your  ideas and solutions are exactly what we need. Section 2.6 [2] explains all.
At least it is exactly what I was looking for but they told me it was impossible!  And I have to agree that I thought it was what we were doing in Lisbon, too…
One ssn, one namespace, multiple ontologies (ontology iris) and every term resolves to the ontology in which it is defined.

Some queries  of clarification from me.

1. I don’t think you are aiming to divorce  SOSA and SSN (i.e my “failure” scenario).  So how do you reconcile “-1 for SOSA and SSN having the same namespace    ” with “ I don't want to need to check whether a term uses the ssn prefix or the sosa prefix… yet, there is a single "owl" namespace.” And whereas 2+ namespaces and 2+ names (SSN and SOSA) demonstrates the group is split in two.”
Are you saying that terms defined in sosa (in its role as the simple core of ssn) and terms deifined in ssn (the bigger part) share a namespace  or not? Am I confused perhaps because you are distinguishing between “namespace’ and “prefix” here?  Or is that quote from you a typo? ““-1 for SOSA and SSN having the same namespace    “

2.  What does (for a term) “.e., the ontology that defines it.” mean?  Does this imply a constraint  that every term in the overall ontology (ie  in your namespace = reachable via imports from your main ontology) )  occurs in only one module? That if it is  defined in one module that it cannot be referenced in any other module?  I know this sounds like a stupid question , but many ssn people are saying that if , say, the ssn module refernces a term from the sosa module  (which is in the same namespace) and you try to resolve that term then it is impossible to return the sosa ontology when it is resolved because the ssn ontology (which does not define the term) occupies that namespace… It looks to me like you are doing term-by-term redirection i.e your htaccess includes a rewrite rule for  every single term? Should this give the W3C  some panic?

3. What would you suggest to a user who comes to ssn and knows they only want the simple version (ie sosa). How do we direct people to the right place when they are not looking for any term in particular, but they are looking for the easy part?

4. Do you have any comment on how the  axiomatic interface between sosa and ssn works? Eg. See my proposal here, https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017   but don’t be confused by namespaces – I am very, very happy to use one namespace.   Some people are apoplectic about the idea there that sosa terms are refined by additional axioms in ssn that strictly (axiomatically) constrain them but remain true to the descriptive definition (that is all sosa is capable of, given its restrictive language). Me, I want every sosa term to be an ssn term in a deeply integrated way. (and so far I have done that backwardly-compatible by only generalising ssn concepts from what they used to be. However sosa as it is will have to change, in general, to make this work nicely).

I don’t suggest you should jump in to your proposed ACTION  without understanding  more about what you would do with this aspect of the marriage..  Under your proposal ssn:sensor subclassof sosa:sensor (my nightmare) is not going to happen but what would it look like? OTOH we already have an unmerged pull request that did  something similar (i.e partially implements an alternative proposal) so if you are will ng to have your PR rejected after it is reviewed and discussed then please go ahead!

And by the way, I want to make VERY clear, I strongly  support your points 1,2,3 and 4 too. It’s a bit hard to support 5 directly – but I am quite sure the many, many ssn users out there would agree.   No one seems to be thinking of our  ssn user base (other than me!).

Kerry


From: Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr]
Sent: Thursday, 2 February 2017 10:46 PM
To: SDW WG Public List <public-sdw-wg@w3.org>
Subject: 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/