Re: Proposals (was Re: Architecture of SOSA/SSN integration)

Okay, I see. Sorry for causing the confusion :-). Great that you agree 
on two namespaces as well!

On 02/01/2017 01:47 PM, Joshua Lieberman wrote:
> Jano,
>
> There is nothing more to “get”. I’m agreeing to two namespaces because 
> people will expect it for two different (if related) concept collections.
>
> Josh
>
>> On Feb 1, 2017, at 4:03 PM, Krzysztof Janowicz <janowicz@ucsb.edu 
>> <mailto:janowicz@ucsb.edu>> wrote:
>>
>> I am really sorry Josh but I still don't get it. We would have 
>> http://www.w3.org/ns/sosa <http://www.w3.org/ns/sosa-ssn> and 
>> http://www.w3.org/ns/ssn <http://www.w3.org/ns/sosa-ssn>. Both of 
>> them would resolve to an information resource about each of them in 
>> the same way we did for the old-SSN. This also provides a very easy 
>> handle to understand whether somebody uses/implies the more generic 
>> SOSA class or a version that also adds additional axioms, i.e., the 
>> SSN class. A namespace is a very nice way to do this and in line with 
>> the dereferencing you mentioned as well as popular services such as 
>> prefix.cc <http://prefix.cc>. We are not giving up on anything with 
>> having two namespaces, we are just increasing usability.
>>
>> Jano
>>
>>
>>
>> On 02/01/2017 12:52 PM, Joshua Lieberman wrote:
>>> The simplest possible meaning here. If a namespace is defined 
>>> somewhere, such as an ontology document, then people expect to be 
>>> able to use the namespace definition also as a URL that resolves to 
>>> information about everything that is defined / identified in that 
>>> namespace. If we have:
>>>
>>> sosa-ssn: http://www.w3.org/ns/sosa-ssn
>>>
>>> sosa-ssn:SosaVocabulary
>>> sosa-ssn:SsnOntology
>>>
>>> People will still expect to be able to resolve 
>>> http://www.w3.org/ns/sos-ssn alone and it will need to document or 
>>> at least point to both constructs. To accommodate this idiosyncratic 
>>> behavior and still “isolate” SOSA, we’ll need to have separate SOS 
>>> and SSN namespaces.
>>>
>>> —Josh
>>>
>>>
>>>> On Feb 1, 2017, at 3:42 PM, Krzysztof Janowicz <janowicz@ucsb.edu 
>>>> <mailto:janowicz@ucsb.edu>> wrote:
>>>>
>>>> Hi Josh,
>>>>
>>>>> I’m also reluctantly agreeing that we should use two namespaces 
>>>>> because a number of people have pointed out that linked data users 
>>>>> increasingly expect namespaces to be overloaded with meaning and 
>>>>> resolvable to documentation as URL’s in their own right.
>>>>
>>>> Could you explain what you mean here? I am not sure whether I am 
>>>> following your argumentation. For something like a namespace 
>>>> resolver, e.g., http://prefix.cc/ , having two namespaces would be 
>>>> great; see also Phil's follow-up email.
>>>>
>>>> Best,
>>>> Jano
>>>>
>>>>
>>>>
>>>> On 02/01/2017 12:34 PM, Joshua Lieberman wrote:
>>>>> Phil,
>>>>>
>>>>> Thanks for making the proposal. I think that’s where we’ve been 
>>>>> converging, that terms are defined informally in SOSA to have the 
>>>>> same scope as in SSN, so that they can be reused in SSN. There are 
>>>>> not a lot of formal mechanisms to make that distinction clear, 
>>>>> however, so we have to use narrative and other tools to indicate 
>>>>> character of each term set (SOSA: core vocabulary and SSN: 
>>>>> ontology built from core vocabulary adding additional concepts).
>>>>>
>>>>> I’m also reluctantly agreeing that we should use two namespaces 
>>>>> because a number of people have pointed out that linked data users 
>>>>> increasingly expect namespaces to be overloaded with meaning and 
>>>>> resolvable to documentation as URL’s in their own right.
>>>>>
>>>>> My preference is for Prop 2A as the term profile is also variously 
>>>>> used (most assume it means a Type 1 profile that restricts the 
>>>>> scope of the profiled specification).
>>>>>
>>>>> The most important alignment for both SOSA and SSN from an OGC 
>>>>> point of view is with O&M and to SensorML. I hope we can focus on 
>>>>> the statements for that to pull this together.
>>>>>
>>>>> —Josh
>>>>>
>>>>>> On Feb 1, 2017, at 3:12 PM, Phil Archer <phila@w3.org> wrote:
>>>>>>
>>>>>> Thanks for pointing out that there is more to SSN than what's in 
>>>>>> the mapping table, I should have checked that.
>>>>>>
>>>>>> OK, so then I do think the SSN-only terms should be in the ssn 
>>>>>> namespace, but where a term exists in SOSA, that's the one we 
>>>>>> use. I don't think that SSN-only terms should be defined in the 
>>>>>> SOSA namespace. Therefore, my proposals become:
>>>>>>
>>>>>> Proposal 1: That where vocabulary terms are defined in the SOSA 
>>>>>> namespace, no new term should be defined for SSN.
>>>>>>
>>>>>> Then:
>>>>>>
>>>>>> Proposal 2A: That SSN is characterised as a semantic layer on top 
>>>>>> of SOSA, with additional terms.
>>>>>>
>>>>>> OR
>>>>>>
>>>>>> Proposal 2B: That SSN is characterised as a profile of SOSA.
>>>>>>
>>>>>> I hope this slight change does not diminish your support Krzysztof.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/02/2017 18:33, Krzysztof Janowicz wrote:
>>>>>>> Dear Phil, all,
>>>>>>>
>>>>>>> Thanks a lot for your thoughts and providing this overview. I 
>>>>>>> would like
>>>>>>> to express my *strongest* possible support for your proposal and 
>>>>>>> hope we
>>>>>>> can finally move forward and understand that no single solution will
>>>>>>> make everybody perfectly happy. What you are proposing is largely in
>>>>>>> line with what many of us have been suggesting and working on for
>>>>>>> months. Please find detailed comments in line.
>>>>>>>
>>>>>>>> I believe the currently published document expresses the consensus
>>>>>>>> view that SOSA is the semantically light weight core and that 
>>>>>>>> SSN is
>>>>>>>> the semantically richer and more specific ontology.
>>>>>>>
>>>>>>> Yes, exactly. But please let me add a few more important detail 
>>>>>>> here.
>>>>>>> SOSA is not only lightweight it also targets a different audience,
>>>>>>> namely those that would typically be attracted to schema.org 
>>>>>>> <http://schema.org/>-style
>>>>>>> semantic annotations. Hence, SSN can/should "use" (e.g., import
>>>>>>> subclass, load, profile, etc. [use whatever term makes you happy 
>>>>>>> here])
>>>>>>> SOSA but not the other way around. Consequently, SOSA has to be 
>>>>>>> designed
>>>>>>> in a way that it can be used entirely independently of SSN. On 
>>>>>>> the other
>>>>>>> hand, SSN really has to use SOSA in some way and here is why: As we
>>>>>>> discussed before, SOSA also acts as a interoperability fallback 
>>>>>>> level.
>>>>>>> What we do *not* want is that SOSA and SSN users cannot exchange 
>>>>>>> data.
>>>>>>> However, and following the current design principles of SOSA, 
>>>>>>> SOSA also
>>>>>>> acts as common core of both, and, thus SSN users and SOSA users can
>>>>>>> indeed exchange data although they do so on a more abstract 
>>>>>>> level. If
>>>>>>> you like object-oriented design/programming, then this idea 
>>>>>>> should sound
>>>>>>> familiar as it is underlying interfaces, generics, inheritance, 
>>>>>>> and so
>>>>>>> forth, and it has been immensely successful.
>>>>>>>
>>>>>>>> It defines a class of Actuation that does not appear in SSN or the
>>>>>>>> others. Nothing more to say.
>>>>>>>
>>>>>>> Yes, and this is not a problem. Same for Sample. We simply 
>>>>>>> forgot about
>>>>>>> this in the old-SSN.
>>>>>>>
>>>>>>>>
>>>>>>>> Both SOSA and SSN have an Observation class. In my view,
>>>>>>>> ssn:Observation should be deleted and SSN users should use
>>>>>>>> sosa:Observation. Ditto for all classes where any differences 
>>>>>>>> can be
>>>>>>>> ironed out.
>>>>>>>
>>>>>>> Yes, exactly. This is where many of us hope to go and this is 
>>>>>>> what has
>>>>>>> been proposed over and over again. Btw, Observation is really 
>>>>>>> the only
>>>>>>> critical part here as O&M and old-SSN had a clear difference 
>>>>>>> here. This
>>>>>>> is not dramatic, just something that we need to work on. I have some
>>>>>>> ideas for this that would also solve our current hasValue problem (I
>>>>>>> wrote an email about this some days ago and will report back on 
>>>>>>> results
>>>>>>> asap with the hope to receive feedback).
>>>>>>>
>>>>>>>> But again, it's the SOSA namespace that wins. If we need to 
>>>>>>>> tweak the
>>>>>>>> SOSA definitions, do it.
>>>>>>>
>>>>>>> Yes!
>>>>>>>
>>>>>>>>
>>>>>>>> Then we get to sosa:ObservableProperty and ssn:Property.
>>>>>>>>
>>>>>>>> Looking at the two definitions, there are differences but they look
>>>>>>>> very minor to my eyes with sosa:ObservableProperty looking slightly
>>>>>>>> more general, so, again, I'd delete ssn:Property.
>>>>>>>
>>>>>>> Yes! And keeping in mind that SOSA is more general by design. 
>>>>>>> This also
>>>>>>> explains why from a set-theoretic perspective SOSA categories 
>>>>>>> (due to
>>>>>>> the lightweight semantics of SOSA classes) are more inclusive 
>>>>>>> than SSN
>>>>>>> categories and, in fact, contain them. Please also note that due 
>>>>>>> to the
>>>>>>> fact that SOSA has a more lightweight semantics, we need more 
>>>>>>> detailed
>>>>>>> human readable class descriptions and this is why we have a bit more
>>>>>>> text and examples then we had in the old-SSN. In the old-SSN we also
>>>>>>> made some mistakes that we can clean up, nobody is perfect after 
>>>>>>> all.
>>>>>>>
>>>>>>>>
>>>>>>>> Only when we get to sosa:Result do we see something different, i.e.
>>>>>>>> ssn:SensorOutput and ssn:ObservationValue. OK, so here, for me, are
>>>>>>>> the only classes in the ssn namespace, both of which are 
>>>>>>>> subclasses of
>>>>>>>> sosa:Result.
>>>>>>>
>>>>>>> We need to change how we handle values as this part got lost when we
>>>>>>> removed the direct linkage to DUL. I am working on this based on 
>>>>>>> the new
>>>>>>> version of the QUDT ontology (http://qudt.org/). This will make 
>>>>>>> sure we
>>>>>>> are compatible with a very important and widely used ontology. I 
>>>>>>> will
>>>>>>> report back on my results as soon as we have agreed on your 
>>>>>>> proposal.
>>>>>>> Otherwise I will have to change everything over and over again.
>>>>>>>
>>>>>>>> What's the difference between sosa:hosts and 
>>>>>>>> sosa:attachedSystem ? Do
>>>>>>>> we need both?
>>>>>>>
>>>>>>> SOSA should not have an attachedSystem relation. Do you mean SSN?
>>>>>>>
>>>>>>>>
>>>>>>>> Hang on, that's *it*. There is no more.
>>>>>>>
>>>>>>> Agreed. This is why we have always tried to highlight that 
>>>>>>> although we
>>>>>>> have different opinions and different proposals, they differ by 
>>>>>>> rather
>>>>>>> small pieces. Almost all of us agree that we can 
>>>>>>> adjust/align/integrate
>>>>>>> SOSA and SSN without major efforts.
>>>>>>>
>>>>>>>>
>>>>>>>> Question: do we really need ssn:SensorOutput and 
>>>>>>>> ssn:ObservationValue
>>>>>>>> or could we live with just sosa:Result?
>>>>>>>
>>>>>>> See above. This problem will go away on its own.
>>>>>>>
>>>>>>>> Based on the mapping table, I end up with just *two* classes 
>>>>>>>> and *no*
>>>>>>>> properties in the SSN namespace.
>>>>>>>
>>>>>>> There is more to SSN, namely survival ranges of sensors and so 
>>>>>>> forth.
>>>>>>>
>>>>>>>> So we're talking here about SSN essentially adding further semantic
>>>>>>>> constraints on SOSA, not new terms (except possibly two new 
>>>>>>>> classes).
>>>>>>>
>>>>>>> SSN contains more, see above. Deployment is another example. 
>>>>>>> This is not
>>>>>>> a problem as these classes and relations do not appear in SOSA. 
>>>>>>> SOSA is
>>>>>>> simply not the place where one would go into all the details on 
>>>>>>> how a
>>>>>>> sensor is constructed and so on, but SSN allows us to do so.
>>>>>>>
>>>>>>>> The SOSA vocabulary (it doesn't have rich enough semantics to be
>>>>>>>> called an ontology in my view) is deliberately defined with loose
>>>>>>>> semantics - just enough for everyday applications.
>>>>>>>
>>>>>>> I am fine with calling it a vocabulary but as it has OWL axioms 
>>>>>>> I would
>>>>>>> prefer to call it ontology. Again, I am fine with whatever the 
>>>>>>> majority
>>>>>>> wants. Maybe 'vocabulary' is even better for our envisioned end 
>>>>>>> users.
>>>>>>>
>>>>>>>> We've been arguing about the namespace for the SSN terms. Kerry has
>>>>>>>> been saying that we don't need another namespace. Reading 
>>>>>>>> through the
>>>>>>>> mapping table, now I see why: personally, I only see one 
>>>>>>>> vocabulary.
>>>>>>>
>>>>>>> This is where I would personally disagree as SSN adds 
>>>>>>> substantially more
>>>>>>> content (see above) and end users tend to confuse namespaces and use
>>>>>>> them for communication. Also note that SSN is a bit of an odd 
>>>>>>> name as we
>>>>>>> ended up not really talking a lot about (N)etworks. That said, 
>>>>>>> and while
>>>>>>> I would strongly prefer two namespaces for clarity, if we all 
>>>>>>> agree to
>>>>>>> go with your suggestion, I will certainly not risk a discussion on
>>>>>>> namespaces if everybody else would prefer just one namespace.
>>>>>>>
>>>>>>>> 6. Alignment to OGC Observations and Measurements
>>>>>>>>
>>>>>>>> Looks like a pretty straightforward alignment to me. I presume
>>>>>>>> consideration was given to using O&M terms directly in SOSA? 
>>>>>>>> Can they
>>>>>>>> not be used directly? If not, it looks to me as if SOSA terms 
>>>>>>>> could be
>>>>>>>> declared as sub classes and properties of O&M terms.
>>>>>>>
>>>>>>> Yes and we have Simon Cox on the team so this should really not be a
>>>>>>> difficult issue. I hope we can give Simon a more active role 
>>>>>>> here but
>>>>>>> this is a separate discussion. O&M is really important if we want
>>>>>>> SOSA/new-SSN to be a success story.
>>>>>>>
>>>>>>>> What about om-lite and sam-lite?
>>>>>>>
>>>>>>> IMHO, om-lite is a subset of O&M and is already compatible with 
>>>>>>> SOSA. In
>>>>>>> fact, Simon posted an alignment between SOSA and om-lite in 
>>>>>>> summer of
>>>>>>> 2016 on our github.
>>>>>>>
>>>>>>>>
>>>>>>>> 8. Alignment to DOLCE+DNS Ultralite upper ontology (DUL)
>>>>>>>>
>>>>>>>> For me this is optional but if there's no harm in including it, 
>>>>>>>> go ahead.
>>>>>>>
>>>>>>> This is a problematic point especially with respect to old-SSN and
>>>>>>> new-SSN. I can demonstrate why this is problematic in a separate 
>>>>>>> email
>>>>>>> but I would strongly suggest we have the DUL alignment as an 
>>>>>>> optional
>>>>>>> part. Which should not be confused with me saying that it does not
>>>>>>> matter. Also note that the idea of 
>>>>>>> contextualized/scoped/optional axioms
>>>>>>> does not exist in W3C OWL.
>>>>>>>
>>>>>>>>
>>>>>>>> Proposal 1: That all vocabulary terms are defined in the SOSA 
>>>>>>>> namespace.
>>>>>>>>
>>>>>>>> Proposal 2A: That SSN is characterised as a semantic layer on 
>>>>>>>> top of
>>>>>>>> SOSA.
>>>>>>>>
>>>>>>>> OR
>>>>>>>>
>>>>>>>> Proposal 2B: That SSN is characterised as a profile of SOSA.
>>>>>>>>
>>>>>>>> Personally, I'd vote in favour of 1 and 2B.
>>>>>>>
>>>>>>> I would vote for 1 but this is probably a more difficult discussion.
>>>>>>>
>>>>>>> Dear SSN members, please let us accept Phil's proposal without 
>>>>>>> getting
>>>>>>> into little infights, very particular details, changes, endless 
>>>>>>> change
>>>>>>> request, and so forth as we did over the past 6+ months. No proposal
>>>>>>> will ever make everybody absolutely happy but Phil's proposal 
>>>>>>> comes from
>>>>>>> a neutral stance and captures almost all aspects we discussed so 
>>>>>>> many
>>>>>>> times and that many of us supported by their votes over and over and
>>>>>>> over again. More details remain to be clarified, but let us do this
>>>>>>> after we agreed on this general outline.
>>>>>>>
>>>>>>> Jano
>>>>>>>
>>>>>>>
>>>>>>> On 02/01/2017 08:40 AM, Phil Archer wrote:
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> I am sorry that I was only able to take part in the first half 
>>>>>>>> of the
>>>>>>>> meeting yesterday.
>>>>>>>>
>>>>>>>> I've been looking at the mapping table [1] and trying to make some
>>>>>>>> more sense of what I see and offer how I personally would choose to
>>>>>>>> proceed. In doing this I admit that I have been too lax, 
>>>>>>>> allowing the
>>>>>>>> task force to continue its work without taking the time to 
>>>>>>>> understand
>>>>>>>> the detail of what was being discussed. This is unhelpful and I 
>>>>>>>> bear
>>>>>>>> some responsibility at least for the current malaise. I offer what
>>>>>>>> follows as a possible way forward. In doing so, please be sure 
>>>>>>>> that I
>>>>>>>> do not have any special powers. This is not a diktat from W3C, 
>>>>>>>> just a
>>>>>>>> proposal from a WG member.
>>>>>>>>
>>>>>>>> I believe the currently published document expresses the consensus
>>>>>>>> view that SOSA is the semantically light weight core and that 
>>>>>>>> SSN is
>>>>>>>> the semantically richer and more specific ontology.
>>>>>>>>
>>>>>>>> OK, so we start with SOSA.
>>>>>>>>
>>>>>>>> It defines a class of Actuation that does not appear in SSN or the
>>>>>>>> others. Nothing more to say.
>>>>>>>>
>>>>>>>> Both SOSA and SSN have an Observation class. In my view,
>>>>>>>> ssn:Observation should be deleted and SSN users should use
>>>>>>>> sosa:Observation. Ditto for all classes where any differences 
>>>>>>>> can be
>>>>>>>> ironed out.
>>>>>>>>
>>>>>>>> But again, it's the SOSA namespace that wins. If we need to 
>>>>>>>> tweak the
>>>>>>>> SOSA definitions, do it.
>>>>>>>>
>>>>>>>> Then we get to sosa:ObservableProperty and ssn:Property.
>>>>>>>>
>>>>>>>> Looking at the two definitions, there are differences but they look
>>>>>>>> very minor to my eyes with sosa:ObservableProperty looking slightly
>>>>>>>> more general, so, again, I'd delete ssn:Property.
>>>>>>>>
>>>>>>>> Only when we get to sosa:Result do we see something different, i.e.
>>>>>>>> ssn:SensorOutput and ssn:ObservationValue. OK, so here, for me, are
>>>>>>>> the only classes in the ssn namespace, both of which are 
>>>>>>>> subclasses of
>>>>>>>> sosa:Result.
>>>>>>>>
>>>>>>>> On to properties.
>>>>>>>>
>>>>>>>> Using the same logic, I would delete:
>>>>>>>>
>>>>>>>> ssn:featureOfInterest
>>>>>>>> ssn:observationResult
>>>>>>>> ssn:observes
>>>>>>>> ssn:observedProperty
>>>>>>>> ssn:sensingMethodUsed
>>>>>>>> ssn:madeObservation (and move ssn:observedBy to the sosa 
>>>>>>>> namespace to
>>>>>>>> be consistent with the other inverse properties)
>>>>>>>> ssn:onPlatform
>>>>>>>> ssn:observationSamplingTime
>>>>>>>> ssn:observationResultTime
>>>>>>>>
>>>>>>>> What's the difference between sosa:hosts and 
>>>>>>>> sosa:attachedSystem ? Do
>>>>>>>> we need both?
>>>>>>>>
>>>>>>>> Hang on, that's *it*. There is no more.
>>>>>>>>
>>>>>>>> Based on the mapping table, I end up with just *two* classes 
>>>>>>>> and *no*
>>>>>>>> properties in the SSN namespace.
>>>>>>>>
>>>>>>>> Question: do we really need ssn:SensorOutput and 
>>>>>>>> ssn:ObservationValue
>>>>>>>> or could we live with just sosa:Result?
>>>>>>>>
>>>>>>>> So we're talking here about SSN essentially adding further semantic
>>>>>>>> constraints on SOSA, not new terms (except possibly two new 
>>>>>>>> classes).
>>>>>>>>
>>>>>>>> That's what I call a profile, i.e. a way in which a particular
>>>>>>>> vocabulary is used, complete with cardinality constraints and more
>>>>>>>> finely tuned semantics. We can add textual usage notes and
>>>>>>>> descriptions as well as semantic axioms but I see no new terms 
>>>>>>>> to add.
>>>>>>>>
>>>>>>>> So here's my table of contents for the document:
>>>>>>>>
>>>>>>>> 1. Introduction
>>>>>>>> 2. Developments since the initial 2009 publication of SSN
>>>>>>>> 3. Modularization
>>>>>>>> 4. The SOSA ontology
>>>>>>>> 5. The SSN Semantic Layer
>>>>>>>> The SOSA vocabulary (it doesn't have rich enough semantics to be
>>>>>>>> called an ontology in my view) is deliberately defined with loose
>>>>>>>> semantics - just enough for everyday applications.
>>>>>>>>
>>>>>>>> Where more precise semantics are needed, such as in @@@use 
>>>>>>>> case@@@ and
>>>>>>>> @@@ use case@@@ an additional layer can be applied. This allows 
>>>>>>>> data
>>>>>>>> encoded using SOSA to be processed using an OWL resoner.
>>>>>>>>
>>>>>>>> Then define all the semantics you like in a file at /ns/ssn/.
>>>>>>>>
>>>>>>>> We've been arguing about the namespace for the SSN terms. Kerry has
>>>>>>>> been saying that we don't need another namespace. Reading 
>>>>>>>> through the
>>>>>>>> mapping table, now I see why: personally, I only see one 
>>>>>>>> vocabulary.
>>>>>>>>
>>>>>>>> 6. Alignment to OGC Observations and Measurements
>>>>>>>>
>>>>>>>> Looks like a pretty straightforward alignment to me. I presume
>>>>>>>> consideration was given to using O&M terms directly in SOSA? 
>>>>>>>> Can they
>>>>>>>> not be used directly? If not, it looks to me as if SOSA terms 
>>>>>>>> could be
>>>>>>>> declared as sub classes and properties of O&M terms.
>>>>>>>>
>>>>>>>> I'd say that this can be part of the normative definition of SOSA.
>>>>>>>>
>>>>>>>> What about om-lite and sam-lite?
>>>>>>>>
>>>>>>>> Well, they look pretty similar too. Am I right that these are
>>>>>>>> CSIRO-only ontologies? In which case, I'd say that any 
>>>>>>>> alignment is up
>>>>>>>> to CSIRO to do and publish.
>>>>>>>>
>>>>>>>> 7. Alignment to SSN of the SSN-XG, ssn-ssnx.
>>>>>>>>
>>>>>>>> I'd include those assertions in a sub chapter of the one on SSN.
>>>>>>>>
>>>>>>>> 8. Alignment to DOLCE+DNS Ultralite upper ontology (DUL)
>>>>>>>>
>>>>>>>> For me this is optional but if there's no harm in including it, 
>>>>>>>> go ahead.
>>>>>>>>
>>>>>>>> I am feeling very guilty. I should have looked at that mapping 
>>>>>>>> table
>>>>>>>> before now. I think I have learned a lesson.
>>>>>>>>
>>>>>>>> Proposal 1: That all vocabulary terms are defined in the SOSA 
>>>>>>>> namespace.
>>>>>>>>
>>>>>>>> Proposal 2A: That SSN is characterised as a semantic layer on 
>>>>>>>> top of
>>>>>>>> SOSA.
>>>>>>>>
>>>>>>>> OR
>>>>>>>>
>>>>>>>> Proposal 2B: That SSN is characterised as a profile of SOSA.
>>>>>>>>
>>>>>>>> Personally, I'd vote in favour of 1 and 2B.
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] https://www.w3.org/2015/spatial/wiki/Mapping_Table
>>>>>>>>
>>>>>>>> On 31/01/2017 23:39, Armin Haller wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Herewith I am trying to summarise what has been discussed in 
>>>>>>>>> today’s
>>>>>>>>> meeting, what was discussed and proposed on the list and what 
>>>>>>>>> we have
>>>>>>>>> already decided on earlier in the working group:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ·         SOSA and SSN use Slash URIs/IRIs
>>>>>>>>>
>>>>>>>>> ·         SOSA and SSN use different IRIs and are serialised in
>>>>>>>>> separate ontology files (everyone expect Kerry agreed on that one,
>>>>>>>>> although there is her proposal on the wiki stating the same:
>>>>>>>>> https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ·         SOSA and SSN may use different ontology namespaces
>>>>>>>>>
>>>>>>>>> ·         SOSA uses simple semantics as decided upon earlier (i.e.
>>>>>>>>> owl classes, datatype and object properties, inverse 
>>>>>>>>> properties, but
>>>>>>>>> no domain/range and no other owl restrictions)
>>>>>>>>>
>>>>>>>>> ·         SSN imports SOSA
>>>>>>>>>
>>>>>>>>> ·         SSN introduces stronger semantics, using several 
>>>>>>>>> types of
>>>>>>>>> OWL restrictions. As far as I can tell, four options have been
>>>>>>>>> presented to add these additional semantics through the import 
>>>>>>>>> of SOSA:
>>>>>>>>>
>>>>>>>>> 1.       SSN introduces new classes/properties in its ontology
>>>>>>>>> namespace and introduces where appropriate equivalence 
>>>>>>>>> relations to
>>>>>>>>> the class/property in SOSA
>>>>>>>>>
>>>>>>>>> 2.       SSN introduces new classes/properties in its ontology
>>>>>>>>> namespace and introduces subclass relations and where appropriate
>>>>>>>>> equivalence relations to the class/property in SOSA
>>>>>>>>>
>>>>>>>>> 3.       SSN reuses the IRI for classes/properties defined in SOSA
>>>>>>>>> and introduces further axioms that “narrow” their meaning, but 
>>>>>>>>> does
>>>>>>>>> not introduce subclass or equivalence relations relying on the 
>>>>>>>>> user
>>>>>>>>> to choose through the ontology namespace the interpretation of the
>>>>>>>>> ontology.
>>>>>>>>>
>>>>>>>>> 4.       A separate core essentially introduces vocabulary 
>>>>>>>>> terms with
>>>>>>>>> no semantics, only a description and a label (very abstract, 
>>>>>>>>> similar
>>>>>>>>> to the annotations that I have added to the wiki
>>>>>>>>> https://www.w3.org/2015/spatial/wiki/Mapping_Table and we had 
>>>>>>>>> no time
>>>>>>>>> to discuss), but its own IRI and “ontology” namespace. Both 
>>>>>>>>> SOSA and
>>>>>>>>> SSN import this vocabulary and extend it with different semantics,
>>>>>>>>> solving the issue that SSN has two different IRIs for some
>>>>>>>>> classes/properties as would be the case in Option 1-2.
>>>>>>>>>
>>>>>>>>> I had the impression that there was no strong objection 
>>>>>>>>> against any
>>>>>>>>> of these options in the call today, but several issues have 
>>>>>>>>> been raised.
>>>>>>>>>
>>>>>>>>> ·         In option 3 the issue that has been raised was that 
>>>>>>>>> users
>>>>>>>>> who use a class/property in their tool of choice may not know 
>>>>>>>>> which
>>>>>>>>> semantic interpretation should be used in the given context.
>>>>>>>>>
>>>>>>>>> ·         Earlier on the mailing list, an issues has arising 
>>>>>>>>> that in
>>>>>>>>> Option 3 SSN would use the SOSA IRIs for several 
>>>>>>>>> classes/properties
>>>>>>>>> whereas the old SSN only had one IRI for those classes/properties.
>>>>>>>>> That could potentially be solved with Option 4.
>>>>>>>>>
>>>>>>>>> Please let me know if I missed an option.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Armin
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Phil Archer
>>>>>> Data Strategist, W3C
>>>>>> http://www.w3.org/
>>>>>>
>>>>>> http://philarcher.org <http://philarcher.org/>
>>>>>> +44 (0)7887 767755
>>>>>> @philarcher1
>>>>>
>>>>
>>>>
>>>> -- 
>>>> 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
>>>
>>
>>
>> -- 
>> 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
>


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