See also: IRC log
<phila> scribeNick: Kjanowic
Is anybody willing to model actuation in SSN
<ahaller2> Kjanowic: I volunteered, but we had other conversations in between
<ahaller2> Kjanowic: until next telco
<Zakim> Kerry, you wanted to remark I think maxime did that yesterday
kjanowic to draft SSN axioms on Actuators and Actuation for next week
Kerry: can kjanowic look into the proposal of Maxime?
kjanowic: yes
ahaller2: yes, let's see what else is out there
yes
Ahaller2: a lot of discussion of
how to model values and results n SOSA and SSN
... Danh willlook into the results/values issue and coordinate
with kjanowic
Danh: Yes, I will do so and review the material and work with kjanowic. I will create a wikipage as overview.
Ahaller2: In general using wikipages for all these subtasks would be good.
<ahaller2> ACTION: DanhLePhuoc to create a wiki page and discuss options around the use of Results in SSN/SOSA [recorded in http://www.w3.org/2017/02/07-sdwssn-minutes.html#action01]
<trackbot> Error finding 'DanhLePhuoc'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<ahaller2> ACTION: Danh to create a wiki page and discuss options around the use of Results in SSN/SOSA [recorded in http://www.w3.org/2017/02/07-sdwssn-minutes.html#action02]
<trackbot> Created ACTION-264 - Create a wiki page and discuss options around the use of results in ssn/sosa [on Danh Le Phuoc - due 2017-02-14].
Ahaller2: we changed back and forth between processes and procedures.
<kerry> sorry folks -- lost all power to house
Ahaller2: what we currently have
currently is a procedure as the description of workflows, e.g.
like recipe.
... I can look into this
<ahaller2> ACTION: Armin Create to create options for the modelling of Processes/Procedures in SOSA and SSN https://www.w3.org/2015/spatial/track/issues/89 (create Action Item) [recorded in http://www.w3.org/2017/02/07-sdwssn-minutes.html#action03]
<trackbot> Created ACTION-265 - Create to create options for the modelling of processes/procedures in sosa and ssn https://www.w3.org/2015/spatial/track/issues/89 (create action item) [on Armin Haller - due 2017-02-14].
<Zakim> kerry, you wanted to ask for current topic
Ahaller2: we are currently assigning action items
<ahaller2> Create Options for alignment on Platform class (create Action Item)
Ahaller2: we had many discussions around the concept of a platform.
<ahaller2> https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN
Ahaller2: one such proposal was by kerry.
kerry: that was really only an
example
... the point I was trying to make was the style, not the
concrete example
... I think we lost a bit of that original proposal made by
kjanowic at the very beginning
Ahaller2: about namespaces?
kerry: the example I gave works in both ways
Ahaller2: not sure what you mean?
SimonCox: Kerry, have you looked at the work we did before on that?
Kerry: bidirectional
interoperability is lost now from kjanowic original
proposal
... we probably gave up on horizontal by now but the proposal
as such is still valid
Ahaller2: please let us get back
to ‘platform’
... namespaces will be discussed next week
Kerry: not about namespaces
Ahaller2: we want to discuss ‘platform’ now
let's get back on topic guys....
Ahaller2: we looked at architecture last week, but we got stuck at namespaces. We will discuss this next time.
lets get back to the topic and also note that other people are on the call
Kerry talks about properties of her suggested approach
<roba> its when restrictions change semantics, rather than axiomitize them that this gets messy
Kerry: I have a well worked proposal for platform
<kerry> no!!!!
ahaller2: kerry, so please tell us about your platform idea
kerry, please lets get less emotional
<ahaller2> https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN
ahaller2: we already agreed on the fact that ssn will import sosa
<rtroncy> Can someone summarize what is the exact issue with the definition of a "Platform" ? (regardless where this term will be defined or refined)
Ahaller2: please look at the proposal and just extract the platform part.
rtroncy has a question and I believe it is important
there are more people on this call...
Kerry: it is all already
there
... should I do a change list
ahaller2: make a wiki/example for platform only
<ahaller2> Kjanowic: if we look at the mapping, the SSN definition for Platform is more generic
<ahaller2> Kjanowic: SOSA should be more generic in its annotation
<ahaller2> Kjanowic: axiomatically they are equivalent
rtroncy: kjanowic answered the question [difficult to understand...]
<kerry> issue-88?
<trackbot> issue-88 -- Why is a sosa-core platofrm completely different to an ssn:platform? -- open
<trackbot> http://www.w3.org/2015/spatial/track/issues/88
kjanowic was tring to answer rtroncy question
<rtroncy> I also asked whether the problem was not described in issue-88?
<rtroncy> It seems so ...
Ahaller2: can you make one wikipage just for ssn and sosa platform without the general architecture, just the platform.
<ahaller2> ACTION: Kerry to Create change list for alignment on Platform class in a seperate wiki page [recorded in http://www.w3.org/2017/02/07-sdwssn-minutes.html#action04]
<trackbot> Created ACTION-266 - Create change list for alignment on platform class in a seperate wiki page [on Kerry Taylor - due 2017-02-14].
Ahaller2: next topic o&m alignment
Ahaller2: let us briefly talk
about annotation properties for examples in SOSA/SSN
... idea was to split definition and example.
<ahaller2> Option 1: Use skos:example in SOSA/SSN and declare it an owl annotation property
Ahaller2: this is especially important for sosa due to less axioms
<ahaller2> Option 2: Define our own annotation property -- e.g. sosa/ssn:example
ahaller: please vote on option 1
<ahaller2> Proposed: Use skos:example in SOSA/SSN and declare it an owl annotation property
<rtroncy2> +1
<DanhLePhuoc> +1
<SimonCox> +1
<RaulGarciaCastro> +1
+1
<laurent_oz> 0
<ahaller2> +1
<kerry> +1 subject to not importing skos
<roba> +1
<ScottSimmons> +1
Ahaller2: do we want to import skos?
<rtroncy2> There is no need to import
<ahaller2> Option: Import or not import SKOS?
<SimonCox> -1 no import of skos
<RaulGarciaCastro> -1
kjanowic: if we only use skos:example there is not need to import
<ahaller2> PROPOSE: If skos:example is the only class/property in either SSN or SOSA we do not import SKOS
+1
<phila> +1
<kerry> +1
<rtroncy2> +1
<ahaller2> +1
<RaulGarciaCastro> +1
<roba> +1
<DanhLePhuoc> +1
<ScottSimmons> +1
<phila> I see no reason to import SKOS
<laurent_oz> no import (but more general concern about the compatibility of reuse of schema.org meta-model and use of skos (e.g. like in RDF data cube)
<SimonCox> +1 - I would extend to any SKOS annotation property
<ahaller2> Kjanowic: what about multiple examples?
<SimonCox> i.e. I would say would could use any SKOS annotation property without importing SKOS
<ScottSimmons> I must leave the meeting, if things come down to close votes, SimonCox has my proxy
<phila> +1 SimonCox
+1 SimonCox
laurent_oz: [too much noise]
<rtroncy2> Raphael: yes, we could make multiple occurrences of skos:example but I would like to remind that they are just annotation properties and as such, there could be redundancy in the information.
SimonCox: the way you posed the issue was limited to only skos:example. If we talk about annotation properties, we have no problem anyway. We can use any of the skos annotation properties withou the need to import.
<rtroncy2> Raphael: I would therefore just use one occurrence of the property even if it gathers multiple examples in the literal
ahaller2: let us make this another agenda item
Kerry: we should have multiple skos:example triples when needed
<ahaller2> PROPOSE: use multiple skos:example annotation properties where necessary
I am also in favor of multiple examples being possible
<roba> +1 for all annotations : i think its consistency requirement - we need to follow the same pattern - so i think the vote implies the default position is we should treat all skos annotations the same way
<SimonCox> +1
<ahaller2> +1
+1
<DanhLePhuoc> +1
<rtroncy2> 0
<kerry> +1
<laurent_oz> +1 to multiple examples (but also keen on having other resources to learn from outside the ontology)
<RaulGarciaCastro> +1
<roba> +1
Ahaller2: let us move to O&M alignment
SimonCox: I did this on github but just posted the text in an email so that you can all look at it.
<ahaller2> SimonCox: email to the list Tue, 7 Feb 2017 21:36:29 +0000
SimonCox: there is an officially endorsed version of how to convert from UML to URLs (by ISO)
<SimonCox> https://github.com/ISO-TC211/GOM/tree/master/isotc211_GOM_harmonizedOntology/19156/2011
SimonCox: my proposal is to use
those URIs for the alignment
... this enables us to express the alignment in a pretty
compact way and not just text
<kerry> simon, did you mean alignment from sosa to ssn as you said?
SimonCox: the question really is
whether the official ISO URIs are suitable to denote the UML
classes and properties.
... would this become normative or not.
... om-lite could also be added as note
<Zakim> kerry, you wanted to coment on what an O&M alignment looks like
<DanhLePhuoc> +q
SimonCox both SOSA and SSN
Kerry: I get the URL idea but
this is really ugly.
... Alternative is to use the OGC O&M specs and do any
alignment to O&M by text
SimonCox: the OWL you get from the automatic conversion is ugly but I am not suggesting that. I am focusing on the nice side effect of minting URLs and those are defined in a standard and are canonical.
<laurent_oz> 1: tried to derive graphics out of the ISO .ttl (result not very good) 2. am now looking at the published UML - found that here was also "implementation" packages in it 3. questions to Simon: are there plan to publish O&M in this branch of HMMG (this could be the best source to derive OWL from).
<laurent_oz> Also: they are official URIs but very badly defined (need some tidying)
Roba: the alignment is a separate document. It is my understanding that it does not effect SSN or SOSA axioms
simoncox: no, same document
... but yes, this does not change sosa/ssn
<ahaller2> ahaller2
Roba: the intention is just to use the URIs?
<ahaller2> ahaller2: it is not a vote yet on if it is normative or non-normative
<laurent_oz> ... e.g. when I say tidying, I mean tracking the official prefixes and removing the ones which have number at the end.
simonCox: yes, that is the idea
Roba: last comment. Skos
notations could be used here.
... SKOS notation not annotation.
... I am just saying that this is an option.
<SimonCox> laurent_oz: don't intend to do anything with the prefixes. Use the official ISO URIs
<Zakim> kerry, you wanted to cjeck thatthose uris are resolvable
kjanowic: simon's proposal is to establish formal relations between the URIs and classes and properties in SOSA/SSN
Kerry: These URIs are not resolvable.
<laurent_oz> Simon, sometimes a nice prefix is used in some places and a different one is used elsewhere: my idea is to use the most recognisable one (so that in the future if we have a better OWL version it will use the same prefixes (likely) and so our work will not be lost.
kerry: fine with me but may be a problem for ssn
laurent_oz: I tried to look into this and visualize it but that was not easy. Do we know what is on the horizon for O&M?
SimonCox: this is a persistent standard in its own right.
<ahaller2> kerry: was pointing out the non-resolving of URIs may be an issue for W3C, check with Phila
laurent_oz: not all of them are easily readable URLs
<ahaller2> URIs are restricted to https://github.com/ISO-TC211/GOM/tree/master/isotc211_GOM_harmonizedOntology/19156/2011, is this correct, Simon?
<roba> Agree with Simon regarding the appropriateness of the URI, and there is a bigger question about OGC/ISO definitions space- alignment with specref may provide a good solution here IMHO
Ahaller2: last topic for having
longer meetings, e.g., some time in Feb.
... I will prepare a doodle.
... this is just about mappings, i.e., alignment. nothing
more
bye bye
<kerry> bye!
<RaulGarciaCastro> Bye
<DanhLePhuoc> bye bye