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

Dear Kerry, all,

1. I don’t think you are aiming to divorce  SOSA and SSN (i.e my “failure”
> scenario).
>

Indeed I am not, I would just like SOSA to be thought of as a "code name"
for what could become something like "the SSN Vocabulary", or "the SSN
light profile"



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


Ooooh that's a typo.....
-1 for SOSA and SSN having separate namespaces
+1 for SOSA and SSN having the same namespace.

Anyways, let's keep technicalities aside for now, let me first issue the
pull request as I suggested, We'll discuss the implications then.



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

That's something like it. there would be a 303 redirection from each term
to the ontology document where it is defined. That should not give the W3C
some panic. But again, that's technicalities we could discuss on the pull
request, once it's ready.


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

The documentation is the key. As François said about the SDB-BP, we should
really finish that last sprint as soon as possible and focus on the
documentation after that. My proposal focuses on technical solutions, so I
suggest we find answer to your question in a separate thread.


> 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 understand your point and the others'. I will not comment any further on
this. Please let me first blindly apply what I did for the SEAS ontologies
to SSN. We will then be able to discuss on something that is there, and not
something "hypothetical".



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

I wouldn't mind my pull request to be rejected, I just want to give the
chance to comment on a tangible technical solution. I believe it could be a
satisfiable compromise for everyone.


> 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!).
>

Thank you.

Maxime


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