Spatial Data on the Web SSN Sub Group Teleconference
28 February 2017
<ahaller2> +1
<SimonCox> +1
<mlefranc> +1
<RaulGarciaCastro> +1
<KJanowic> +1
<roba> +1
No objection to last week's minutes
roba: Did we resolve...?
… I thought we had an open issue on the integration architecture, but it's not on the agenda
ahaller2: It's on next week's plenary meeting. I'm waiting for people to vote on the current options
[No comment on Patent Call]
ahaller2: Simon has made a proposal.
SimonCox: Look at the wiki page there - this is text I had put into the draft of the spec that people couldn't find so I copied it to the wiki
… 8.1 I propose can be dropped directly into the spec.
… It proposes SOSA classes and properties being dropped in, plus OGC/ISO standard
… Using those URIs to denate the classes and properties from the UML model
… Intention is not to imply endorsement of the OWL implementation
… It's a convenient naming convention that we voted on last time.
… Only going to be focussed on section 8.1 that I propose is made normative
… Aligns SOSA/SSN with original UML model
… Laid out as a table
… Links to an RDF file that encodes this
SimonCox: I found it useful to ... for the alignment... some local classes...
… That's been on the table for a couple of weeks. Lower half suggests alignment to OM Lite
… That hasn;t had any use AFAIK apart from the paper so it shouldn't be normative but might be included as an informative annex.
SimonCox: The graphs are available but I haven't done the documenting (scribe missed a bit of that)
roba: Can you clarify, in 8.1, you have equivClass except for Feature of Interest which is sub class. Why?
SimonCox: This might overlap with some of the discussion we've had about the feature Of Interest cf. Spatial Thing
… My understanding is that when we introduced this, we explicitly identified the subclass of all spatial things as @@@ ?
roba: Looks a bit weird without a rationale
ahaller2: We had a discussion earlier about alignment that Kerry proposed
<KJanowic> +1 for DL functional syntax :-)
<tidoust> Phil: How do you define a subclass? You write in text in the spec, then in RDFS in the RDF.
SimonCox: I created tables that essentially recreate triples
<tidoust> Phil: I think what you've written there is perfectly clear. The rule is to make it clear, which you've done!
phila: What you've done there is fine
… HTML needs to be clear (it is) then in the RDF use owl:equiavlentClass as you have. Job done
<roba> agree its clear... as long as we are consistent across different alignment docs
KJanowic: (missed q)
SimonCox: You're asking about the first 2 alignments
<ahaller2> KJanowic: asked about the iso19156-om:OM_Process
… equivalent class
… sosa:Sensor or sosa-om:ObservationProcedure
[Discussion between KJanowic and SimonCox on whether alignment of @@@ is correct]
<KJanowic> I suggested a subclass relation for the iso19156-om:OM_Process part and asked whether we are all fine with iso19156-om:OM_Observation
… equivalent class
… sosa:Observation (which I am but it may be controversial)
DanhLePhuoc: I had a question about the alignment.
SimonCox: Are you suggesting a warning/caveat?
<KJanowic> what kind of warning and why?
DanhLePhuoc: Do you expect there will be a use cases for this alignment?
SimonCox: It's not inconceivable.
… The OWL implementations of the ISO standard are publicly available.
… The likelihood of them being used in a traditional SemWeb reasoning context isn't great as I expect the work we're doing here should overtake it.
<KJanowic> May still be relevant for legacy data
SimonCox: The interest here is to give ourselves a mechanism to denote those classes and properties
<KJanowic> yes, exactly
SimonCox: The legacy data, maybe from SOS systems, encoding in XML corresponding to the UML??
DanhLePhuoc: I'm thinking this might be useful for mapping legacy data
… If you do this alignment, you can do this
<KJanowic> or for transparent proxies
<ahaller2> DanhLePhuoc: Is proposing to have an example to legacy applications
DanhLePhuoc: Maybe in the BP section, we can show how to bring legacy data to the new form
kerry: Just checking that the discussion is focussed on section 8.1
kerry: I note that KJanowic was asking about presentation but I note that he was questioning it. Is there something that can be added
<KJanowic> These would be formal axioms anyway, right?
SimonCox: I can add the word UnionOf in brackets
kerry: Good, thanks
<ahaller2> or as proposed earlier DL functional syntax
kerry: Did you do any formal checks... whether there are any problems if you put this in a reasoner together with SOSA? My guess is that you don't but has it been done?
SimonCox: No.
kerry: Then I think DanhLePhuoc's idea of adding in the caveat that this is just about the URIs make sense
SimonCox: I have a list of 4 mods to do so far.
KJanowic: Am I right that those ...
SimonCox: The formal axioms are in the RDF graph
KJanowic: I think this is very useful, not just for legacy data
KJanowic: Re the axioms, Rob and I suggest a way of minting our own classes and then defining a relation...
… The fact that they're not resolvable should be OK.
SimonCox: On the resolvability - we have been in correspondence with the TC211 folks and triggered renewed interest.
… Slight trap in the transfer from Norway to Sweden but I think it's worth nagging away. Hopeful of resolution not in weeks but in months
phila: Yep, progress is being made towards best solution so worth waiting.
kerry: Some of this work - which is very good - assumes some things that are under discussion, such as the names of some of the props and classes
kerry: If we move to a vote, then I'd like to put a caveat on that.
kerry: Personally, I don't think any of those changes, if they happen, won't change things substantially here.
SimonCox: I worked on the basis of SOSA as it was 3 weeks ago. Any changes to SOSA would have knock on effect to naming at least, yes.
SimonCox: For 8.2 - 8.4 I prepared those to show how the horizontal and vertical could work. It can go away if you like or it cojuld be an annex, which I think would be the right way forward
ahaller2: So you're suggesting 8.1 as normative, 8.2 - 8.4 to the annex.
SimonCox: In the OGC, it's normal to use annexes to give more pedagogical examples
phila: Same at W3C too
kerry: I am uncomfortable with ... given that OMLite has no uses that we know of... I would suggest that we can't afford to do this work in this WG
kerry: We have a lot of work to do around this, so I'd be happier for it to be deferred to the proposed follow up group (post June
kerry: For clarity - 8.2 onwards in new Note from new WG. 8.1 in current doc
KJanowic: I'd like to point out OBOE ontology which is very popular in Earth Sciences
<SimonCox> OBOE
KJanowic: having an alignment in an appendix broadens our potential audience
<SimonCox> I'm familiar witOBE
SimonCox: I can comment on OBOE
… Alignment won't be so easy
<KJanowic> sorry for my audio quality: IMHO, we should have these alignments in the appendix because they matter and will ensure we have a large user base (and that we do the alignment and not others)
SimonCox: I have one between OM Lite and OBOE
SimonCox: OBOE observations are collections of observations
<KJanowic> I agree with the problem you mention but this is exactly the reason for the alignment
SimonCox: SInce we don't have a notion of a coherent collection in SOSA/SSN, which is how OBOE works, this would be non-trivial
SimonCox: I could look at it thought
<KJanowic> e.g. in dataONE
SimonCox: But I think KJanowic's point is important. OBOE is an OWL ontology in wide use in the biodiversity world
KJanowic: The key issue is as you mentioned. Measurement and support etc. This is why we should be doing the alignment. So we can point out where we use the same name to mean different things.
<roba> three seperate issues then: values of om-lite alignment, need for OBOE, and opportunity to "show how" alignment should be done (and if they are to be computable, then we need them to follow common mechanisms
kerry: To stress again, we don't have any descriptive documentation, no relation to the UCR etc. I don't dispute its usefulness, but I'm not sure we can take it on with so many open issues etc.
kerry: I think the right place for this is an associated thing
<KJanowic> I do not see this as something new but just as stating the relation between our work and others thereby enabing interoperability
kerry: It's good work to be done. It needs attention, but with 4 months to go, I'm not sure we have time.
<KJanowic> it should be an appendix
ahaller2: On that aspect... it seems to me... the text is there. If we don't have any objections to the text we have then I see no reason not to put it in an annex
ahaller2: The question is - is there anything that we object to in 8.2?
<KJanowic> imho, ensuring that others can easily use our work is very, very important and alignment to common ontologies is exactly this
<KJanowic> OBOE is also widely used
kerry: Putting that text in there, without more time on those other ontologies, and implying that we accept those as part of the WG as well, is a strong statement from the WG
roba: I'm going to agree with everyone.
… In an ideal world we would have time to test everything. We could say that the informative annex gives initial thinking, make it clear that it doesn't have the same level of attention that the normative bits have.
KJanowic: You're proposing that 8.1 is normative and the rest in a non-normative appendix. We're doing an alignment to Dolce, and OBOE is no less important
KJanowic: We can say that the OBOE piece is not complete
roba: No one's arguing about normative/non-normative. I am proposing that we put a much stronger caveat on the early thinking
<KJanowic> But those 'example' wouldl be in owl, right?
roba: "Don't use it yet"
SimonCox: I'm not going to die in the trenches to get the OMLite alignment in here. I think OBOE is much more important
ahaller2: So it sounds like we just incorporate 8.1 for now
<KJanowic> Sounds good to me
SimonCox: Yes, but I'll tidy up the other pieces in case we want it
<KJanowic> I would prefer an alignment with a clear statement that it is early work to having no alignment at all
<tidoust> Phil: I hope we'll be much more advanced after the upcoming F2F. There might be a way to express the uncertainty and so on. I'm a bit hesitant.
<tidoust> ... We could also publish that as a Note, which can contain basically anything that the WG wants to put it in.
<tidoust> ... Let's try not to throw good work away.
<tidoust> ... We'll see after the F2F meeting.
kerry: I'd like to remind us that we have about a dozen other bits of related work we could do.
… There's SefkiKolozali's work on time etc.
… There is other work that is at least as advanced as this
… I'd argue that the same process should apply
<KJanowic> IMHO, this depends on how widely these other ontologies are used or what the reasons for inclusion might be.
kerry: There are many potential bits of work with similar status
<tidoust> Phil: I'm just looking now on the group's home page. The way we handle what Kerry just said in other groups is as follow: we do need to focus at this stage, only 4 months left! The way you do that is to set up a wish list. That wish list could help drive the proposed IG as well.
<roba> wish list is basically what i was proposing..
<ahaller2> phila: Proposes to setup a wishlist that documents semi-mature work that we know we want to do
SimonCox: Thanks everyone for pointing out the other suggestions for alignments.
… I've found it useful to bring it to the group for discussion
… others might find the same
<KJanowic> I am also fine with the wish list if this is the minimal compromise we can all agree on.
kerry: We do already have a wish list
… recent restructuring may have pushed it down the page
<mlefranc> https://www.w3.org/2015/spatial/wiki/SSN_Wish_List
kerry: Things there may not have the same level of maturity that Simon's wwork has
Action: SimonCox to incorporate Section 8.2 into the editors draft, incorporating modification discussed today and update the wiki in regards to 8.2 - 8.4 to decide later on a way to include them, potentially in a note
<trackbot> Error finding 'SimonCox'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<roba> we would need to reference the wish list in the doc I guess
Action: Simon to incorporate Section 8.1 into the editors draft, incorporating modification discussed today and update the wiki in regards to 8.2 - 8.4 to decide later on a way to include them, potentially in a note
<trackbot> Created ACTION-272 - to incorporate section 8.2 into the editors draft, incorporating modification discussed today and update the wiki in regards to 8.2 - 8.4 to decide later on a way to include them, potentially in a note [on Simon Cox - due 2017-03-07].
ahaller2: Use of VOAF in SOSA and/or SSN
<mlefranc> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0195.html
mlefranc: There is a discussion about the possible use of VOAF.
<ahaller2> mlefranc: Ontology instances are instances of owl:Ontology and voaf:Vocabulary.
mlefranc: We might use VOAF to describe the ontology
mlefranc: People seemed to like it mostly, also VANN.
… Which may be another agenda item
ahaller2: The question is do we include it in SSN, SSN and SOSA or not at all.
<KJanowic> there was also a proposal from roba to include this into its own file
kerry: We had some objection about using it in SOSA
<ahaller2> PROPOSAL: Put VOAF into SSN to make ontology instances voaf:Vocabulary
+1
<mlefranc> +1
<kerry> +1
<SimonCox> +1
<ahaller2> +1
<RaulGarciaCastro> 0
<KJanowic> 0
<roba> +1
<DanhLePhuoc> 0
Resolved: Put VOAF into SSN to make ontology instances voaf:Vocabulary
KJanowic: Just to recall that ... what was your proposal Rob?
roba: We could have separate files for any flavour of metadata we choose
… One for DCAT, one for something else. Just a possibility I raised, not a concrete proposal.
<ahaller2> PROPOSAL: Put VOAF into SOSA to make ontology instances voaf:Vocabulary
<mlefranc> +1
ahaller2: That's part of the integration discussion
+1
<ahaller2> +1
<SimonCox> +1
<kerry> +1
<RaulGarciaCastro> 0
<DanhLePhuoc> 0
<KJanowic> 0 (if we do so on a case-by-case basis)
<roba> Agree that provision of multiple flavours of metadata can be addresses in integration architecture, then "in SOSA" will have a specific implementation implication
KJanowic: [Garbled]
Resolved: Put VOAF into SSN to make ontology instances voaf:Vocabulary
<KJanowic> (if we do so on a case-by-case basis) --> if we discuss each metadata vocabulary individually
<Zakim> phila, you wanted to ask the 0 folks why
<Zakim> RaulGarciaCastro, you wanted to answer Phil
RaulGarciaCastro: I don't have a clear idea what we're planning to annotate.
… The other properties we have, they're not going to be used, no?
<ahaller2> +1 to RaulGarciaCastro, only stating that SSN/SOSA is a VOAF:Vocabulary
<KJanowic> +1 to Raul
RaulGarciaCastro: For me it doesn't add much. Anyone will entail that an ontology is a vocab
<KJanowic> I agree with Raul and put myself off the queue
DanhLePhuoc: For me, I agree with RaulGarciaCastro and I also add, I don't see much added value to this property.
… From a practical POV you're adding more triples for no real reason
DanhLePhuoc: If it doesn't help, why add it?
<KJanowic> +1 to Danh and also you have to ensure that those vocabularies stay and are stable and so on
<mlefranc> https://www.w3.org/2015/spatial/wiki/Make_SSN_reachable_from_SOSA_using_seeAlso_and_comment
mlefranc: I understand those points. Asserting that ontologies are instances of voaf:vocabulary... points to wiki issue.
… You could discover that there is an ontology that adds new axioms to SOSA
<KJanowic> But we can also do so with rdfs:seeAlso
ahaller2: All we just decided was to use VOAF
<RaulGarciaCastro> But for getting into LOV you need more than just having that triple
<ahaller2> +1 phila
phila: If a vocab is not in LOV, I won't find it. End of
<RaulGarciaCastro> You don’t even need the triple (SSN is already there and does not have it)
KJanowic: I see Phil's point, but how many vocabs are as well maintained?
KJanowic: If you use terms from another ontology, you want to know whwo maintains it?
<Zakim> phila, you wanted to talk about Ian Davies
zakim close queue
<KJanowic> But there are also many examples were they are not used e.g., in dbpedia, provo-o, and so forth. Again, I am not arguing against them but trying to explain the problems that people report
<RaulGarciaCastro> Just stating that the ontology is a voaf:Vocabulary doesn’t add much; we could also say that the ontology is a prov:Entity, and similarly for many others
<KJanowic> phila, and you believe that VANN adds something that we really need to state?
<ahaller2> scribe kerry
<ahaller2> scribenick kerry
phila: Yes KJanowic
<roba> back in 5...
ahaller2: maxime do you want to intro vann?
mlefranc: van -- there is some confusion about namespace and ontology
mlefranc: namespace is identified by prefixes and in xml but are not part of rdf standard
… so this is the chance to precice those concepts
… you have an rdf term that is [missed]\
… and have at least one instance of an ontology that is defined in it
… so if the file is accessible at some url for instance
… [scribe not keeping up]
… vann allows you to define the namespace and url for the ontology
… is widely used
… same question as for voaf...
… use in sosa / use in ssn
ahaller2: question is that a lot of integration prposals use namespace same as uri and some different
<ahaller2> PROPOSAL: add vann:preferredNamespacePrefix and vann:preferredNamespaceUri metadata in ssn
<RaulGarciaCastro> +1
<phila> +1
<mlefranc> +1
<ahaller2> +1
<KJanowic> 0
ahaller2: lets vote on ssn first
+1
<SimonCox> 0
<DanhLePhuoc> 0
<KJanowic> roba is afk for 5 min
Resolved: add vann:preferredNamespacePrefix and vann:preferredNamespaceUri metadata in ssn
<ahaller2> PROPOSAL: add vann:preferredNamespacePrefix and vann:preferredNamespaceUri metadata in SOSA
<RaulGarciaCastro> +1
<ahaller2> +1
<KJanowic> 0
<phila> +1
ahaller2: second one is to put it in sosa
+1
<mlefranc> +1
<SimonCox> 0
<DanhLePhuoc> 0
Resolved: add vann:preferredNamespacePrefix and vann:preferredNamespaceUri metadata in SOSA
ahaller2: moving on
<roba> back...
ahaller2: maxime you proposed this
mlefranc: ther are tow little changes I made
… updated dcterm:rights --- should we use this?
… also dcterms: licence do we need this?
<SimonCox> Aren't rights and license subject to W3C/OGC rules?
mlefranc: alo want to use titles and descriptions that are aligned and reference each other in sosa and ssn
<SimonCox> ALso need to add OGC license!
RaulGarciaCastro: I can ask an expert in our group to advise on the best way for this
… whether to link to text or urls for example
… offering to ask for advice on this
ahaller2: also need to include ogc in rights
mlefranc: agreed about ogc, but it is just a matter of doing ourself - what is w3c advice on best practice here?
phila: I think....
… looking at previous ones and I can't see anything anywhere
… i can't see any reference to any kind of licence in TR namespace docs
… found one but it is not one of ours...
… no --- very often there is nothing
… so examples of bad practice
mlefranc: so voaf or dcterms or both for licence?
phila: we separate the doc in TR from the ontology in the namespace
… I can't see an ns document that also has a tr doc that talks about licence in namespace doc
… the tr space doc carries the IPR normally
ahaller2: so we could leave it out
phila: that is what I would do
<ahaller2> PROPOSAL: To include licence statement in the TR space only, not in the ontologies
<mlefranc> 0
<ahaller2> PROPOSED: To include licence statement in the TR space only, not in the ontologies
-1
<mlefranc> 0
<RaulGarciaCastro> -1
<KJanowic> 0
<ClausStadler> 0
<SimonCox> -1
<roba> 0
<DanhLePhuoc> 0
<ahaller2> kerry: terms are well defined, it should go in the ontology
<ahaller2> ... even if it is not a best practice
kerry: it should go into ontology -- why not?
RaulGarciaCastro: agrees it should be propoer in ontology
<ahaller2> PROPOSED: To include licence statement in the SSN ontology
<RaulGarciaCastro> +1
<KJanowic> 0
<mlefranc> 0
<ahaller2> 0
<DanhLePhuoc> 0
+1
<SimonCox> +1
Resolved: To include licence statement in the SSN ontology
<ClausStadler> 0
<ahaller2> PROPOSED: To include licence statement in the SOSA ontology
<SimonCox> +1
Action: daoust to look into whether we can/should add licence statement to /ns docs and, if so, which one
<trackbot> Created ACTION-273 - Look into whether we can/should add licence statement to /ns docs and, if so, which one [on François Daoust - due 2017-03-07].
<RaulGarciaCastro> +1
<roba> +1
<mlefranc> 0
<KJanowic> 0
<ahaller2> 0
+1
<ClausStadler> 0
<DanhLePhuoc> 0
Resolved: To include licence statement in the SOSA ontology
<RaulGarciaCastro> Sure
<SimonCox> who is here?
ahaller2: asking raul to check with colleague for advice on best way.
Action: Raul check with colleague on a way to formalise licenceses in ontology
<trackbot> Created ACTION-274 - Check with colleague on a way to formalise licenceses in ontology [on Raúl García Castro - due 2017-03-07].
phila: am asking francois to give formal advice and also Scott
<mlefranc> https://www.w3.org/2015/spatial/wiki/Ontology_rights_and_licence
mlefranc: i would like you to consider at least a url or what text is needed in this advice
… [might have missed some of that]
ahaller2: maxime to comment?
mlefranc: again this is just on a triple by triple basis
… the old ssn used skos;note
… should this be changed?
<SimonCox> FWIW - OGC software license is here: http://www.opengeospatial.org/ogc/Software
mlefranc: i tried to work on a triple basis and to decide what should be included in sosa, ssn, ssnz to make them look alighed
… so q is old ssn used skos:note
… see 3 options on wiki
… and what *should* we use?
ahaller2: skos:history note or dc:source or [missed]
<ahaller2> Option: skos:historyNote dcterms:source owl:versionInfo
<ahaller2> PROPOSE: use skos:historyNote in SSN
<roba> depends on the content of the note...
<KJanowic> agree with roba
ahaller2: yes in ssn dcterms: source is used and sosa uses skos: historynote but not for each term
mlefranc: says we should be consistent
… depends on content of note
<RaulGarciaCastro> From the SKOS primer: “”skos:historyNote describes significant changes to the meaning or the form of a concept:”
roba: thay are all slighly seprate options and they may all be relvant
… quite nice to have all those things..
<ahaller2> PROPOSED: dcterms:source for terms in SOSA
ahaller2: dcterms:source in ssn would stay
<mlefranc> +1
<ahaller2> 0
+1
<RaulGarciaCastro> +1
<roba> +1
<DanhLePhuoc> +1
<ClausStadler> +1
<SimonCox> 0
<KJanowic> 0
Resolved: dcterms:source for terms in SOSA
ahaller2: resolved
<SimonCox> SOSA is lightweight, many influences, how many shall we credit?
<ahaller2> PROPOSED: use skos:historyNote in SSN
ahaller2: now same question in opposite direction as skos:history note is already used in sosa
<RaulGarciaCastro> -1, it does not seem to be the expected usage of the property
<KJanowic> good point Simon, and my concern as well
<mlefranc> 0
<ahaller2> my concern as well to not overload SOSA
RaulGarciaCastro: use of skos:history note is not as it is intended
<RaulGarciaCastro> https://www.w3.org/TR/skos-primer/#secdocumentation
RaulGarciaCastro: so history note is to describe sig changes to meaning or form of term
… and we are not doing this
ahaller2: so we should remove from sosa?
<roba> remove - or rename?
<ahaller2> PROPOSE: remove skos:historyNote from SOSA
<phila> +1
<mlefranc> +1
<RaulGarciaCastro> +1
<ahaller2> +1
<KJanowic> lets not overload sosa
0
<DanhLePhuoc> +1
<ClausStadler> +1
<SimonCox> +1
<KJanowic> +1
<roba> +1
Resolved: remove skos:historyNote from SOSA
<SimonCox> There is no history!
..now look at version info, maxime?
<phila> +1 to SimonCox
<RaulGarciaCastro> https://www.w3.org/TR/owl-ref/#versionInfo-def
mlefranc: just quickly we are resolving this issue on wiki page
… we just resolved issue of annotation for every term
… we could sue dcterms:source for the terms in ssn
<KJanowic> There is only one historynote in sosa and it points to the orginal modularization idea
<SimonCox> Shouldn't we be dealing with these documentation/metadata issues *after* the group has done the substantive work. Largely editorial => leave it to the editors??
mlefranc: and as we are now talking about annotating the ontology as a whole we should use versionInfo for the ontology itself , in both ontologies
… and agree that skos:historyNote is not the right one
<ahaller2> PROPOSE: Use owl:versionInfo in SSN
ahaller2: to clarify we would need a proposal to remove dcterms:souirce from ssn and we have not said that -- so it stays by default
<ahaller2> PROPOSED: Use owl:versionInfo in SSN
<ahaller2> +1
+1
<mlefranc> +1
<RaulGarciaCastro> +1
<mlefranc> ack
<roba> +1
<phila> +1
<ClausStadler> +1
<DanhLePhuoc> +1
<KJanowic> +1
Resolved: Use owl:versionInfo in SSN
<SimonCox> +1
KJanowic: [garbled] nothing to remove
… i will remove
SimonCox: concerned we are getting bogged down
<KJanowic> I agree with Simon, this is what I tried to say
SimonCox: this is editoral work
roba: was going to ask for clarification on statemnt that sosa is not a version of anything
… but our charter says it is
ahaller2: proposes 5 minute break\
<ahaller2> [5 min] 8:55am
ahaller2: resume at 5 minute sto the hour
<ahaller2> [break]
<RaulGarciaCastro> phila: They are nicer :)
<mlefranc> * excellent :-)
<mlefranc> * will we some day have the audio recorded and/or machine transcription as part of the minutes ?
<KJanowic> nice indeed
<ahaller2> nice! the top looks a bit 90's Web retro style
<roba> ooh - have we got the licence right in case its a best seller?
<roba> the drama, the tension, the deep characterisation !
Armin: Kerry authored a Wiki page where she proposes use of Platform and how that would transfer to "sosa"
Kerry: I see some changes were made to the page, feel free to jump in to explain them.
… I'm proposing to extend SSN to assert that both Sensors and Actuators are Systems.
… I don't think that's controversial although that has not been decided.
… The reason to that is that in SOSA, Sensors can be attached to Platforms. In SSN, Sensors are not Systems.
… The proposal would make it possible to attach Sensors to Systems in SOSA
… That's the key message here
<ahaller2> KJanowic+
Kerry: As a side effect of that, Systems are allowed to be virtual.
… I've particularly suggested for SOSA that we use the SSN terms for these, because they make more sense, have been around for some time, and have been widely used already.
KJanowic: Thanks for the details, I think we are discussing too many things here. I thought it was just a discussion about Platform, but this goes way further.
… [sound chopped, scribe missed point]
<KJanowic> sorry for the audio, I changes location and can try again now
<KJanowic> the many things in one was a comment to your proposal touching on issues of our integration discussion.
Kerry: This has been on the table for 2-3 months. Platform is necessarily introducing a lot of issues because it is a complex concept in SSN.
… The implications of that to SOSA are complex and I can't just make that go away.
… What I've done is my best attempt to make things consistent
… Issues cannot be dealt with one by one.
<KJanowic> we already discussed that the definition of sosa and ssn platform is not inconsistent
Kerry: SOSA used the concept of Platform independently of the way it's been used in SSN.
<KJanowic> sorry for my audio kerry, I changed locations now and can retry
Armin: I don't think there's a lot of issue on the table. What Kerry is proposing is that Sensors and Actuators can be attached to Systems, which seems quite uncontroversial.
… We can replace @@@ by attachedSystem if necessarily.
<KJanowic> I see problems with this proposal
Kerry: There is a bit more than that, to re-work the concept of System to make it work in SOSA.
… It belongs to SSN but it is an extensive issue
mlefranc: I think what Kerry says is important. There are at least 3 votes here.
… Sensors and Actuators as subclass of ssn:System.
<KJanowic> yes, many issues here
mlefranc: Second on the naming.
<KJanowic> there is no system in sosa so "onPlatform/attachedSystem" would be an issue for me
<KJanowic> also kerry "Please bear with me. In particular I am NOT suggesting that sosa:Platform exists at all." I would not be happy with removing platform from SOSA
Kerry: Maybe the separation in 3 issues proposed by Maxime could work?
Armin: Let's give it a try
<ahaller2> PROPOSED: Actuators and Sensors in SSN are made subclass of System
<mlefranc> +1
<ahaller2> +1
<kerry> +1 but note side efects are necessary
<RaulGarciaCastro> +1, that will help us to align with other initiatives (e.g., WoT)
<KJanowic> So human eyes are systems?
<SefkiKolozali> +q
<DanhLePhuoc> +1
<KJanowic> and systems cann be virtual?
<mlefranc> yes
<mlefranc> yes
Resolved: Actuators and Sensors in SSN are made subclass of System
<ahaller2> Actuator and Sensor class, apologies
<ahaller2> please ignore the plural
Sefki: Half question and half statement. If we have many sensors, then they will create a System? If so, how do Platforms can create Systems?
<Zakim> kerry, you wanted to answer
<KJanowic> IMHO, we were supposed to discuss platform here but we are discussing systems and many, many other issues here
Kerry: Sefki raises a very good question. The notion of a Platform hosting a system of sensors does not go away.
… The difference is, if you wanted to go to a Sensor, since a Sensor was not a System, you went through the Device level. That was a way of putting a sensing device as part of a platform.
… This was done with a somewhat more complex mechanism.
… You can still do that, that does not go away.
<SimonCox> what is the functional role of 'System' - is it (a) collections; (b) indirection?
Kerry: If you have a SOSA sensor which is on a Platform, this can be done directly because a sensor is a system in SOSA, which can be part of a Platform.
<KJanowic> again, keep in mind that sosa has no System class
<SimonCox> 'system' is such a generic term, appears in lots of other places, need to be careful about allowing conclusions to be jumped to ...
Kerry: This is a generalization of SSN. It's not really necessary in SSN, but needed for SOSA.
<ahaller2> PROPSOED: There is a property in SSN that allows Sensors or Actuators to be “attached” to a Platform, pending a decision on the name
<mlefranc> +1
<SimonCox> +1
<KJanowic> +1
<kerry> +1
<ahaller2> +1
<RaulGarciaCastro> +1
<KJanowic> (and we have this in sosa)
<ClausStadler> +1
<DanhLePhuoc> +1
<mlefranc> via the System class ?
Armin: Related to that, there needs to be a property in SSN to attach Sensors and Actuators to a Platform.
<SefkiKolozali> +1
Kerry: Right, it is a necessary consequence.
<KJanowic> +1
Resolved: There is a property in SSN that allows Sensors or Actuators to be “attached” to a Platform, pending a decision on the name
<mlefranc> then -1
<KJanowic> This “attached” relation is already in SOSA
<RaulGarciaCastro> -1 if we are not going to use the existing properties
<KJanowic> +1 to maxime
<RaulGarciaCastro> for what mlefranc is saying
<kerry> agreed with Maxime -- that is right
mlefranc: Let's say we choose sosa:isHostedBy and sosa:hosts, I don't see a problem in SSN, because in SOSA, rangeIncludes will do what we want. sosa:hosts can link systems and platforms in SSN.
<KJanowic> so we can keep what we have
Armin: We did not decide on the actual name.
<kerry> +1 to maxime -- that is to mirror this change for sensors and platforms
<RaulGarciaCastro> But the property should go from System, not from Sensor and Actuator
mlefranc: I feared that there could be multipled properties for sensors and actuators
KJanowic: As Maxime just said, we already have sosa properties that we could use directly.
… The only thing that I would object is if we would remove those and introduce a system concept in sosa.
Armin: Right, no one suggests that.
<KJanowic> We have all we need for that in sosa sosa:hostedBy and sosa:hosts . This relates sensors and actuators to platforms. We also do not have a system concept in sosa. We can easily reuse the sosa properties in ssn.
Sefki: My point is with systems of systems, common in IoT, clusters of sensors. Can we do that with this proposal?
<kerry> sefki, you can do that but only with ssn, not in sosa, under this proposal
Armin: Yes, multiple sensors can still be connected to multiple systems. No change there.
<KJanowic> hosted by attaches a sensor/actuator to a platform
Maxime: Is it true that in this form a Platform is the name of a role. Isn't hostedBy another way to say that a system is a sub-system of another system?
<Zakim> kerry, you wanted to respond to sefki and to repond to maxime
Maxime: I'm questioning how different this is from a system being hosted by a platform. The bigger system could be the platform.
Kerry: I actually think you're right that this is a confusion that arises from this proposal.
<KJanowic> I see your point sefki
Kerry: I could not find a way to clarify that and provide directions. I tried but could not really solve that. I thought it just better to leave it open.
… The concept of a platform was a "ship" or a "buoy", with different systems, composed of sensors and actuators.
… I do not think we can be more specific here.
<SimonCox> SensorML terminology is very closely linked to some specific sensor scenarios, particularly ships, satellites, UAVs, aircraft - big platforms which carry complex systems.
<ahaller2> https://www.w3.org/2015/spatial/track/issues/85
Kerry: Your phone could be a system of sensors, and the platform may end up being the same thing in that case, but there's no real problem with that.
<KJanowic> why would platform have to by physical?
<SimonCox> It does not necessarily carry over to other scenarios. The scope of SOSA is arguably more general/relaxed/permissive than SensorML.
Armin: Can you remind us of the resolution on issue 85? Isn't that about the question of having systems part of other systems?
Kerry: No. In this proposal, a system is composed of subsystems, some of these subsystems will be sensors. In the previous SSN, a system was composed of subsystems, and subsystems were composed of sensors.
KJanowic: Again, I think we are trying way too many things here. In many cases, you do not need a system or a platform. The typical example for me for a platform is if you have multiple sensors and you want to keep track of the positions of the relative sensors.
… (cameras example)
Maxime: If I understand well what Kerry is suggesting, you can have systems that are not platforms, systems that are also platforms, systems that belong to platforms. That's fine with me.
… [scribe missed comment on onPlatform]
<KJanowic> so how would systems that are not platforms differ from systems that are platforms?
Rob: Can someone clarify whether we're talking about types of platforms or instances of platforms?
<Zakim> SimonCox, you wanted to comment on scope of SensorML and why it might not be an ideal or complete precedent
<ClausStadler> I think the question can be rephrased as whether a concrete system or its architecture is being modeled?
Simon: Kerry's doing a very good job at reminding us to look at precedents.
… SensorML was such a precedent.
… We need to be a little bit mindful as to where SensorML came from. The idea of systems mounted of platforms was very strong in that community.
<KJanowic> +1 to what Simon said
Simon: When we're moving to other types of systems/platforms, the language changes a little and the precedent in SensorML may no longer be very useful.
… I'm also concerned about the word System itself which is a very generic term.
<Zakim> kerry, you wanted to answer roba
Simon: I'm guess I'd like to call for caution when copying SensorML ideas.
Kerry: We still have that use case for SSN that hasn't gone away, around observations. Still around for coverage work in this group.
… Scientific observations in HIPS.
… Also, for me that's the only way to make sosa work. Alternatives would move heavy-weight.
… The use case that supports the purpose of the Platform concept is still there.
<roba> no one has yet answered whether its types, instances or both?
<KJanowic> why can't it be used in ssn directly?
<mlefranc> @Rob, if in OWL, object properties always link instances
Armin: I think there is just one issue here. In sosa, people want a generic term to attach a sensor to a system or platform. It cannot include "platform" because that would make it hard to use in SSN to attach to systems and not platforms.
… attachs/attachedBy perhaps.
… Trying to find a compromise here.
<roba> no RDF instances, tpyes of devices vs deployments...
<mlefranc> @Rob, you can talk more generally about classes, by using subClassOf some restriction
Kjanowic: To follow-up on SensorML, it's important to understand differences. We already took different decisions in the past.
<ahaller2> ahaller: we need a generic property in SOSA, e.g. hosts/hostedBy or attached/attachedBy and more specific ones that could be a sub-property in SSN, e.g. onPlatform/attachedSystem
<Zakim> kerry, you wanted to say that is not the choice
<ahaller2> https://www.w3.org/2015/spatial/wiki/Platform
<KJanowic> The page, for instance, states that " In particular I am NOT suggesting that sosa:Platform exists at all"
Armin: I don't think we have a disagreement on the Platform class
Kerry: Maybe I need to summarize the page again. This assumes that sosa has a Platform class. Maybe I got that wrong but I don't think so.
… A sensor can be hostedBy/attachedTo a platform, and that can work equally well in sosa and ssn.
<SimonCox> OK - thanks Kerry - that helped.
Kerry: We could separate what that property and inverse property names are, but that property can be used in both sosa and ssn, to attach to systems and platforms.
<mlefranc> @Armin, that's exactly what I wanted to say, let's just choose the names
<mlefranc> proposing hosts/isHostedBy,
Armin: Right, I think the last question is just around the names of the properties.
<KJanowic> System does not exist in SOSA so attachedSystem would be an issue but what about subroles?
Armin: I'm not sure if we can resolve this today or if we need more property names.
Maxime: I think the core issue is how to integrate sosa with ssn. hosts/hostedBy, onPlatform/attachedSystem.
<KJanowic> I agree with Maxime
Maxime: Maybe we can just choose the name, and see the implications on SSN.
<Zakim> kerry, you wanted to say how it is modelled in ssn
KJanowic: given sosa does not have system, so we can keep hosts/hostedBy and create subproperties as needed?
<KJanowic> yes!
<KJanowic> so everything is fine. we are in violent agreement
Kerry: It's even simpler than that, the same property names can be reused in both ontologies
… This is what adjusting the definition of system gives us.
<KJanowic> yes!
<mlefranc> PRO POSAL replace URI of ssn:onPlatform in SSN by sosa:isHostedBy
<ahaller2> yes!
<SimonCox> Violent agreement?
<KJanowic> so can we vote on hosts/hostedBy?
Armin: On the Wiki, there is an option for onPlatform and attachedSystem, and my feeling is that the group thinks these are not good names because they are not generic enough.
<KJanowic> we discussed names for weeks and hosts/hostedBy turned out to be the most neutral
<mlefranc> PRO POSAL replace URI of ssn:attachedSystem in SSN by sosa:hosts
<ahaller2> PROPOSED: have a generic property in SOSA that allows attaching of Sensors/Actuators to Platforms and name it hosts/hostedBy
<mlefranc> -1
<SimonCox> +1
<KJanowic> +1 (we already have this)
<roba> +1
<kerry> 0
<DanhLePhuoc> +1
<kerry> +1 to maxime's comment
<ahaller2> PROPOSED: have a generic property in SOSA that allows attaching of Sensors/Actuators to Platforms and name it hosts/isHostedBy
<mlefranc> +1
<SimonCox> +1
<KJanowic> +1
<kerry> 0
Maxime: I just wonder why we don't have "is" here, because we have it in other places
<RaulGarciaCastro> +1
<ahaller2> +1
<ClausStadler> +1
<DanhLePhuoc> +1
Armin: Fair enough, adjusting the proposal
<roba> +1
Resolved: have a generic property in SOSA that allows attaching of Sensors/Actuators to Platforms and name it hosts/isHostedBy
<KJanowic> I can do that change in sosa.ttl
<SefkiKolozali> +1
<KJanowic> lets vote on using them directly
<kerry> please same!
<mlefranc> +1
Armin: And now the question is, are we using the same properties in SSN or are we using different ones?
<ahaller2> : have a generic property in SSN that allows attaching of Sensors/Actuators to Platforms and Systems and name it hosts/isHostedBy
<mlefranc> +1
<ahaller2> PROPSOED: have a generic property in SSN that allows attaching of Sensors/Actuators to Platforms and Systems and name it hosts/isHostedBy
s|RESOLVED: have a generic property in SSN that allows attaching of Sensors/Actuators to Platforms and Systems and name it hosts/isHostedBy||
<ahaller2> +1
<mlefranc> +1
<RaulGarciaCastro> -1
<kerry> +1 but noting consequence has to be those changes to system as in proposal on wiki
<mlefranc> Sensors/Actuators "as subclassof of system" --> to platform
Raul: If sensors and actuators are systems, why do they need to be associated with systems?
<roba> I dont understand whyt we need another one - arent we just re-using sosa: properties ?
<KJanowic> +1 to roba
Kerry: Before the change, sensors were not systems, but the proposal is to say that a sensor is always a system, and as such you don't really need to associate them with systems
<KJanowic> yes, me too
<KJanowic> ssn uses the sosa properties
<ahaller2> PROPOSED: have the same property in SSN that allows attaching of Sensors/Actuators to Platforms and Systems and name it hosts/isHostedBy as defined in SOSA
<KJanowic> +1
<mlefranc> +1
<roba> +1
<SimonCox> +1
<kerry> +1
<ahaller2> +1
<ClausStadler> +1
<RaulGarciaCastro> My problem is with the “and Systems”
<mlefranc> agree with Raul
Raul: Can we remove the "and systems" from the text?
<KJanowic> (the systems ) would not be in sosa, so no reason to worry. Raul is corect, it is 'automatically'
Kerry: No.
<mlefranc> have the same property in SSN that allows attaching of Systems to Platforms and name it hosts/isHostedBy
<RaulGarciaCastro> have the same property in SSN that allows attaching of Sensors/Actuators and Systems to Platforms and name it hosts/isHostedBy as defined in SOSA
Kerry: Ah, I see Raul's point, let me rewrite the proposal
<kerry> ROPOSED: have the same property in SSN that allows attaching of Sensors/Actuators/systems to Platforms and name it hosts/isHostedBy as defined in SOSA
<ahaller2> PROPOSED: have the same property in SSN that allows attaching of Sensors/Actuators and Systems to Platforms and name it hosts/isHostedBy as defined in SOSA
<RaulGarciaCastro> +1
<ahaller2> +1
<mlefranc> +1
<SefkiKolozali> +1
<roba> +1
<ClausStadler> +1
<KJanowic> +1
<kerry> +1
<DanhLePhuoc> +1
<SimonCox> +1
<mlefranc> any actions ?
Resolved: have the same property in SSN that allows attaching of Sensors/Actuators and Systems to Platforms and name it hosts/isHostedBy as defined in SOSA
<KJanowic> One tiny issue before we stop
Action: Kerry to implement the changes we decided on in SSN and the DOLCE alignment
<trackbot> Created ACTION-275 - Implement the changes we decided on in ssn and the dolce alignment [on Kerry Taylor - due 2017-03-07].
<KJanowic> Armin, one tiny issue
<kerry> bye!
<RaulGarciaCastro> Bye!
<KJanowic> wait
<KJanowic> https://www.w3.org/2015/spatial/track/issues/88
KJanowic: please close issue-88, same as what we discussed.
<SimonCox> Effectively the action resulting from this vote resolves ISSUE-88 ?
<KJanowic> bye bye
<RaulGarciaCastro> Bye
<ahaller2> bye
Armin: Let's wait for the action implementation and close the issue then