Spatial Data on the Web Working Group F2F
21 March 2017
<eparsons> Looks like webex will not start until 08:00 GMT so I will set up a hangout in the meantime...
<eparsons> Use https://hangouts.google.com/hangouts/_/google.com/sdwearly
<eparsons>
… Looks like webex will not start until 08:00 GMT so I will set up a hangout in the meantime... Use https://hangouts.google.com/hangouts/_/google.com/sdwearly
<eparsons> Might get webex sooner if phila can change it...
<mlefranc> hello, no webex untill 9 ?
<eparsons> Webex in 5 mins please wait - phila is here now
<eparsons> Webex now live 111
<eparsons> please move back over...
<eparsons> I will close the hangout...
<eparsons> Kerry : ok to work through options within everyone
mlefranc: to speak to rob's remark,
… to say we haveto write a rule to retrive the right ontology
… this applied to every singel optio on the table
… all of them need 303(?) rules due to slash uris
… i don't see a difference
roba: the diff is (and I have built them), the second option that is an ontology for namespace you only have to substitue a slash for a hash
… and you can do this for every term in onle rewrite rule
<tidoust> i|Kerry: ok to work|Topic: SOSA-SSN Integration
roba: but for this method, unlike others, you have to write a rule for every term
… so if someone wanted an another ontolgy that builds on it they have to put new rules in youir infrastructure
… so less scalable
<tidoust> Remaining Options for SOSA-SSN Integration
roba: becuase you need to negotiate a new rule for each new tool
… wheras extensions all intheri own namespace collapses
mlefranc: in the group we have closed little sets so its easy to write the rules..
… but having one single namespace puts the burden on the ... looking for those terms
… I wanted to hightlight we have 2 options
… there are some questions that can be spearated
… e.g. option 8 relies on content neg..
… we could also write an option 1 that relies on content negotiation
… so we could do this to [missed] but we should keep clear that conneg is not an instrinsic part of the picture
<Zakim> phila, you wanted to talk about infrastructure
mlefranc: i don't think it is a good thing to return different parts of the doc
<mlefranc> speak up please
<mlefranc> (can't hear)
phila: any other examples where content neg is [missed]
… if u want w3c to have on set of rules [cannot hear]
… if you ..feels wrong is not web architecture..
… one uri giving multiple resources breaks a fundamental architecture principle
roba: otion 1 or option 8 do not need content negotiation
… fact that... fundamental distinction. Option 1 and 5 you need to do tricks
… I think this is intersting for this problem -- 8 options when not much guidance
… obviously not a trivial problem
mlefranc: we all agree that we do not want content neg then
… let's get rigd of this
<phila> phila: Web fundamental - different resources have different URIs
<phila> phila: If resources differ by anything other than serialisation, they're different resources and should have a different URI
<Zakim> roba, you wanted to respond to Kerrys question about which options rely on content neg..
roba: the limitation of option 1 is there is no way to fnd axioms for sosa
<joshlieberman> It shouldn't be necessary to go to any resource that imports a particular term other than the originally defining resource.
roba: but could use content negotiation to do that
… option 5 also has the same navigation...
ssn or whatever imports sos and use content negotiation.
but option 8 does not use content negotiation.
<phila> +1 to Rob
... just uses owl imports
joshlieberman: not sure that content neg is a problem
<mlefranc> * kerry you type, I can"t hear
[cannot hear]
... expet to resolve a term where it is originall define
...anyone can import an ontology and extend it
mlefranc: not a prblem eg. for platform ..can use metadata to say that ssn extendes sosa
+1
...would like to mod option 5 to get rid of content negotiation
...so there is a clear difference between them!
+1 yes please agree to that change
<phila> phila: Didn't say conneg is bad. Just that it is limited in its meaning. It gives you different representations of the one resource identified by the URI
... kerry [missed]
kerry: [missed]
<joshlieberman> It seems the difference between 5 and 8 now is the role of the SSN ontology (add axioms versus add terms). Can we combine that?
roba: challenge is that one of the functional requirements is the inability to navigate between a term and its strongert axiomitisation
… my problem is that we cannot talk about the ability to discover axioms is not about pros and cons
… option 1 and option 5 both rely on conneg to provide traversal to full axioms
… optin 1 the nav path is ... [not sure]... if you resilve the uri you get the sosa term
… if u can provide evidence otherwise we need to assess that.
… you cannot reolve the uris without using conneg
… option 5 has standard web aptter and you could use conneg to get the stronger axiomiisation
option 8 is a reposne to the identification of that challenge
... it occurs to me that importas and refactorisation of axioms makes it work
....there may be a coutner arg
...we can't take it out
...but if we can simplify it!
joshlieberman: so could serve full ssn via content neg ... if you indent to get a diff ontology then you should ask for it
… option 5 and option 8 have differnt scope for ssn ontology
… we should say ssn should import sosa add new axioms and new terms
… if you want and only know of the deeper sosoa axiomitisation you should know that and go to the stronget ontology and import it.
mlefranc: if you want stronger go to ssn; if you want lightweight for to sosa
… in this case you need to know where it is defined
… so option 1 also does this
… back to option 8 [end of sosa] as sosa:imports a strionger ontology
<roba> correct "if you follw OWL entaiulment" - but if you dont then there is no problem
mlefranc: you have sosa plus all the owldl in sosa becuase of the imports, and most users would see this and therefore get the owl dl when they do not want it
<phila> kerry: It sounds as if we have consensus that conng should not decide which ontology you receive
<phila> eparsons: Sounds like sense but wait until Armin is here
<mlefranc> back at 9 ?
eparsons: [calls a cofee break until 9am]
<phila> [Back at the top of the hour]
<roba> so i dont lose the thought - the proposition is that people editing in Protege will be confused by getting more via imports. Surely this is explicitly not the SOSA use case - SOSA design goal is to be lightweight and usable outside e of tools that do more complex entailment. My proposition is allow complex tools to do the right thing by explicitly including the relevant statements, (owl:imports) but assume simple cases can work with the resources they find.
<roba> furthermore the decision that "SSN extends _and_ adds axioms" was a design goal - we now know it has implications that we cannot discover axioms deom sosa automatically, and a refactor would allow us to do so using standard behaviours.
<roba> s/.deom/from
eparsons: Explains that we've had a preliminary discussion about SSN options, now omn to coverages
billroberts: Main business to get through if we can is around the CoverageJSON
… Then a progress report on the other 2 docs (eo-qb and qb4st)
billroberts: On CoverageJSON - we discussed this in London
… essence was whether the spec ... which is still evolving... should be part of the doc being produced here or referenced from it.
… Conclusion was thaty it would live elsewhere and our doc would discuss its content and it may be standardised by OGC later
… So there was some restructuring to do.
… Jon apologises for not being able to join the call today. He's done most of the wwork in the last few weeks
<eparsons> Doc is here
<eparsons> http://w3c.github.io/sdw/coverage-json/
billroberts: Minor things to do, tidying up references etc.
… Need to add section to cover relationship with SDW-BP
… I now think it's a good candidate for FPWD
… Take feedback and then do one more version before the end of the WG
<billroberts> http://w3c.github.io/sdw/coverage-json/
[Pause for reading]
eparsons: What are the expectations wrt to future OGC process and time frame?
joshlieberman: There's an OGC Community standard which is accepted by a community but it's not formalised. OGC can adopt but not change
AndreaPerego: If you want to modify it, you'd need to go through the OGC process?
joshlieberman: If the community agrees
billroberts: The status of the spec is that it's close to being final but has not yet been widely applied
… Jon as instigator, wants to encourage use beyond his own group.
billroberts: Jon might aim for a Community Standard
joshlieberman: What we've done here in this WG is simultaneous publication. There's been work done to line up different doc types
joshlieberman: Another evolution that might happen with a Community Standard - in the process of getting something to work, it's not 100% compatible with other OGC standards
… Do we leave it as it is or do some reconciliation work?
… e.g. CIS model cf. CoverageJSON
joshlieberman: KML was a case in point. It was widely adopted. Then there was some pain to align with Simple Features
<Zakim> AndreaPerego, you wanted to ask whether consolidating it via a W3C CG could be an option prior to contribute to OGC
AndreaPerego: You said that it's not widely implemented? Does that make it difficult to be a Community Standard at OGC?
… Maybe a W3C CG might be a good vehicle?
billroberts: Maybe there's a route to continue in W3C/OGC collaboration
… This WG is about to finish
<eparsons> phila: work this week with OGC staff to agree a new joint working group
<joshlieberman> So there may be 3 options: 1) further community development followed by community standard adoption 2) incorporation into an OGC standards development process (SWG) and 3) further OGC-W3C work item
<eparsons> phila: Jon could publish this as a note - but he wants to follow a non W3C route phila could not convince him...
<joshlieberman> OGC document types in order of process weight: Best Practice / Community Standard / Implementation Standard
<eparsons> phila : Not sure we should publish this without advice from W3C staff
eparsons: What would be the status of this doc if we were to publish it now?
tidoust: It would be a FPWD
eparsons: Of what
tidoust: Of itself
tidoust: The doc will say that it's going to be Note, not a rec
billroberts: I think that's well established
billroberts: It's not going to be a Rec, we know that
… So it's a Note or nothing
<joshlieberman> There is some difference in OGC between a discussion paper (interesting work) and a best practice (give it a try, first step of standards track).
joshlieberman: There is a discussion paper, and a best practice which is more heading towards a standard
eparsons: Does it need normative content to be OK?
… Can it just point to other docs?
tidoust: What is the intention? No need to add normative content
tidoust: It could be formulated as a Note about coverages on the Web, with strong ties to CoverageJSON
… and what could be standardised in the future.
billroberts: I understand what you're asking but I don't think it would be useful at this stage.
… a broader doc about coverages on the Web is not what this is for.
… Notes can be very light weight
… The group has been discussing this. Others can look at it and see what it's about.
… It's a review of an existing format
phila: Retracting a little - the WG can publish the doc if it so chooses. I'm registering my own disappointment that Jon is unwilling to publish the spec itself as an OGC/W3C doc (not a formal standard)
billroberts: Would publishing this preclude changing the doc to include the full spec in the doc in future?
Linda: I want to support that. We can as a group to say that we think it's better to include the spec if Jon can be persuaded
Linda: We could wait and then publish but I don't mind publishing what we have now.
tidoust: Putting the coverage JSON in this doc does not mean that we will end up as a standard in future
… It can be at a group level
… tidoust If the WG feels it's important to standardise CoverJSON that be a future work.
eparsons: I agree with Linda that we can publish this now and then raise the issue of potentially adding in the full spec
… So we publish as is, and then raise the issue and see what Jon has to say after that.
billroberts: The essence of the doc wouldn't change substantially. At the moment it has links to sections - we'd essentially bring the text in.
eparsons: The JWOC might provide the environment for future work.
AndreaPerego: The section around the RDF/JSON-LD implementation. namespace is covjson.org - how stable is that? Another option is w3 space?
<tidoust> Phil: I am working with management and systems team to have a simple feature that allows people to publish stuff to w3.org/ns, e.g. from GitHub through one button. I hope to have that soon.
billroberts: covjson.org doesn't have the longevity of w3.org of course. A move in future might be possible
joshlieberman: I think we've decided that if something is in an OGC BP doc, then it can have an OGC namespace
billroberts: When you start the work, you want something you can manage.
<eparsons> PROPOSED: That the editors current draft of the coverageJSON doc at http://w3c.github.io/sdw/coverage-json/ be published by W3C and OGC as First Public Working Draft.
<billroberts> +1
<eparsons> +1
<AndreaPerego> +1
<Linda> +1
<kerry> +1
<joshlieberman> +1
<RaulGarciaCastro> +1
<ahaller2_> +1
Resolved: That the editors current draft of the coverageJSON doc at http://w3c.github.io/sdw/coverage-json/ be published by W3C and OGC as First Public Working Draft.
<eparsons> Congratulations and Thanks to the Editors !!!
billroberts: Thanks everyone. I'll have those discussions with Jon.
<tidoust> [+ note the issue about the future of CoverageJSON near the top of the document before publication]
billroberts: Should we try and schedule a session later today that Jon could join?
eparsons: We can mull it over and have that discussion offline
eparsons: It's not a controversy, we want the best home for the excellent work that Jon and co havae done.
billroberts: Plan is to have one more iteration each
… So there should be new docs in the coming couple of months.
… We had discussion of that on our last call.
sam_toyer: At the moment, eo-qb has only a handful of issues. Need to add references
… Also some feedback we need to incorporate, but they're minor. Missing a short section on implementation and notes for developers
phila: What is your actual time line?
sam_toyer: I can do some this evening. Some is dependent on others. University time line shouldn't present a problem. One student's availability might pose a prob until April
<eparsons> Armin ack next
kerry: I agree with what Sam said. We were hoping to have a new WD by now, but there's not much change since last time so we're not proposing a new publication today?
billroberts: That's right.
… One more publication before the end of the WG.
billroberts: QB4ST - status is similar. If anything it's even closer to being finished. Rob has done all the work on this.
… The call we had recently, the main discussion is around adding examples and there has been some input from Jon on that in the last couple of days as some of the CovJSON egs are good for this
roba: I've done some edits - minor editorial edits from Kerry etc. There were some open issues, mostly wish lists for richer examples
roba: I've clarified a number of pieces around the potential mechanism around hierarchies ... I've simply put in some suggestions
… I've suggested that we can use skos:broader to preserve the hierarchies
roba: No substantive changes to the content or the vocab
… Call to Bill - is it better to go as is? I have no further changes to make.
… I don't have the bandwidth to go into deep detail on the Coverage JSON examples
billroberts: My feeling was that the doc is pretty complete. But more examples would be helpful. It can survive without but it would be better with them.
… It's not details of CovJSON, it's finding a couple of realistic coverages where the terms in your ontology where the temporal dimensions etc, could be demonstrated
roba: I should be able to find some time to work on those.
… Early feedback suggests it's not far from being complete
billroberts: Maybe I should have a go at the examples
roba: We can do a screen share session to work it out.
<Zakim> phila, you wanted to talk about the UN
billroberts: That gives me a chance to be an external tester
<eparsons> phila: reports back from UN meeting of stats division UNGGIM, Geo etc
<eparsons> phila: stats guys pleased with QB4ST !!!
billroberts: On the hierarchies... it makes sense to me to be out of scope for that doc. From a stats POV, I've been working with commercial clients and EU projects
… Talk of reviving a W3C CG on semantic statistics which might be a place to take this forward
roba: Then I think what we have is pretty much done
billroberts: We could publish what we have now then?
… The doc is certainly ready to be published. What do people think?
eparsons: Don't keep it secret
billroberts: The ED is also available
ahaller2_: Talked about SemStats CG and its revival
PROPOSED: That the current working draft of QB4ST at http://w3c.github.io/sdw/qb4st/ be published as a (non-final) WD
<eparsons> +1
<billroberts> +1
<Linda> +1
<kerry> +1
<AndreaPerego> +1
<joshlieberman> +1
<roba> +1
<ahaller2_> +1
Resolved: That the current working draft of QB4ST at http://w3c.github.io/sdw/qb4st/ be published as a (non-final) WD
<RaulGarciaCastro> +1
eparsons: Thanks Bill
[5 minute break]
eparsons: Can Kerry fill Armin in on the earlier discussion about options for namespaces
kerry: There was some discussion about conneg and how that did and didn't relate to the options on the table
kerry: I think there was consensus around not depending on conneg and that might help us move forward
… Rob was raising issues about what happens when you resolve a URI in the ontology
roba: I'll clarify. It's not what happens when you resolve, it's how do you get to the stronger axoims
… I think we're happy on what happens when you resolve the URIs
… The issue raised was that different options have different expectations for user agnet behaviour
… Option 2, without conneg, you have to know in advance whether you want to load SSN or SOSA
… Option 3, non-OWL aware tools won't follow owl:imports
<kerry> https://www.w3.org/2015/spatial/wiki/Remaining_Options_for_SOSA-SSN_Integration
<ahaller2_> can we try to use Option 1, Option 5 and Option 8, just to not confuse anyone
mlefranc: I really think that the distinction between options 1 and 5 doesn't exist. Meaning when you look up a term, because we don't use conneg to serve different resources
… wew need to decide to which ontology each term redirects
<ahaller2_> all options need 303 redirects
mlefranc: It's the same in all options
… There's no complexity added by option 1
… For each term, you need to know for which term it redirects
roba: It's not whether the redirect gets the stronger axioms
mlefranc: But this has not been decided
… We don't know how SOSA will point to SSN
<ahaller2_> Option 1: If you care about that every term has the same namespace, but don’t mind that the stronger axiomatisation of a term may not be directly accessible in a linked data fashion you will like Option 1.
ahaller2_: I want to bring people to yesterday... there are a couple of people who were here yesterday... the main attributes of each option I posted earlier
<ahaller2_> Mean vote result: 0
<ahaller2_> Option 1: If you care about that every term has the same namespace, but don’t mind that the stronger axiomatisation of a term may not be directly accessible in a linked data fashion you will like Option 1.
<mlefranc> (same for the other options)
<ahaller2_> Mean vote result: 0
<ahaller2_> Option 5: If you care about the same reuse mechanism of terms as in Option 1, but don’t mind to have two namespaces and that the stronger axiomatisation of a term may not be directly accessible in a linked data fashion you will like Option 5.
<ahaller2_> Mean vote result: 0.11
<ahaller2_> Option 8: If you like Option 5 and you want to be able to access the stronger axiomatisation of a term in a linked data fashion, but don’t mind that SOSA imports an expressive OWL ontology, you will like Option 8.
<roba> yes - those are accurately described - well done
<ahaller2_> Mean vote result: 0.11
ahaller2_: Option 5 had no -ve votes but 8 did
mlefranc: I'd like the opinions of people who were not here yesterday or this morning
RaulGarciaCastro: In my case, I'm in favour of option 1. That gives the user a unified view of the ontology
… For me, option 8 works, but explaining that they have to use one which imports another etc. seems unnecessary
<kerry> +1 to agree entirely with Raul
<ahaller2_> +1 with Raul that importing owl-dl axioms is confusing for web developers who just one schema.org style
DanhLePhuoc: I also support Raul. The unified view. In the context of schema.org are looking at SOSA and SSN, they're interested in integrating this. And the WoT WG
… They don't want to be confused and don't care about OWL
… They see everything as a data schema
kerry: The 3 options on the table, to summarise and to forget conneg. Option 5 is what everyone has ever seen before.
… They're different ontologies.
<roba> Option 1 does work but it means abandoning decision to separate a simple SOSA core
kerry: We have the clear goal to modularise the ontology. We have a simple form of the ontology and then we have the more complex version with more terms
<ahaller2_> @roba in Option 1 we are not abandoning a simple SOSA core
kerry: This strikes me as a sensible modularity option.
kerry: Option 8 adds an owl:imports into the simple core. My big problem is that it's artificial. I also don't hink it's even possible.
… What we have is some sort of factorisation of what we have: SOSA core, then SOSA axioms, then SSN
… That's a long way from what we have now
<ahaller2_> +1 to kerry
kerry: I think option 8 would be very difficult to do.
<roba> I will make the observation that currently SOSA-OWL-DL would be empty :-)
<roba> so not difficult at all
mlefranc: I agree that option 5 works with slash and hash based URIs
… Option 1 has one namespace that works only with slash-based URIs
… Simon says is that people's expectation is that one namespace gives one ontology not multiple ontologies.
… I agree with Kerry that it would be very difficult to split things.
… So we end up with something like an option between 5 and 8.
… We assume that non-OWL tools will not understand and implement owl:imports
… Non OWL tools will be confused and think that SOSA does not exist
… I think this is dangerous. The imports may lead to loops.
roba: Lots of issues here that might collapse into each other.
… Is this possible or not? Most of the constraints are about subclasses
… Currently SOSA-OWL-DL is unpopulated
… OWL explicity specifies that the closure of import loops are not to be treated as a problem. So we could base our decision on tools that ignore the OWL spec
… So it comes down to whether you want one namespace or two.
… If you want to have one namespace then you're abandoning the idea of SOSA as a pull out simplification.
… Other options are OK but are inconsistent with what we've already agreed. Option 1 does away with SOSA core
ahaller2_: +1 to Danh and Raul
… People who expect a schema.org like simple ontology will get a bunch of axioms they won't understand or expect with option 5
… What Kerry and Maxime said - it would be a challenge to separate the axioms envisaged in option 8
<roba> @Raul - in what way exactly
<RaulGarciaCastro> @roba I will explain
ahaller2_: We are running out of time and option 8 seems to be the one that causes most problem so I'd like to reduce it to a choice between 1 and 5
… Option 1 still has 2 files
joshlieberman: I've spent enough time railing against namespaces and prefixes. The difficulty of managing ontologies on the Web - we want to do the most expected
… One ontology for one prefix
<roba> i disagree about the time commitment - 1 will require major refactoring of sosa + ssn currently in separate namespaces, 8 has 0 extra effort - just mneans SOSA axioms go in a particular file
joshlieberman: The SOSA vocab is most likely to be most useful if there is no connection to SSN
… You don't want unexpected axioms
<mlefranc> @roba, I commit to do the refactoring
<Linda> +1 to josh
<ahaller2_> @roba Option 8 needs careful consideration of every axiom that spans SOSA and SSN terms
joshlieberman: I think I'm supporting 5, but that puts you in an environment...
<Zakim> phila, you wanted to talk about where the modularisation happens
<roba> @ahheler - no - if it spanbs SSN it goes in SSN - very simple
<ahaller2_> @roba, no it can't if the term is introduced in SOSA
<roba> SSN terms, by def, are not in SOSA.. they are in SSN
<tidoust> Phil: What harm is done by a tool that doesn't understand some triples? SSN was too complicated, so modularization was in order. You can do that in documentation. The harm, as Josh said, is that people won't understand the complex stuff if it gets returned with the simple things.
<Zakim> RaulGarciaCastro, you wanted to mention that another "Major con" for option 8 is that it does not conform to the standard expectation of how ontologies are implemented
<tidoust> ... The idea of having redirections based on terms, I strongly disagree with.
RaulGarciaCastro: Option 1 doesn't conform to standard expectations, but nor does option 8
<ahaller2_> @eparsons what about another straw poll?
<eparsons> ahaller2_ Yes I think we are nearly there...
RaulGarciaCastro: @@@ Missed point, sorry@@@
<RaulGarciaCastro> We are proposing to define a set of axioms in an ontology and then import those axioms in another ontology that is the one that is declaring all the ontology terms.
<RaulGarciaCastro> This is something that I haven't ever seen. And not the expected behaviour.
<RaulGarciaCastro> And we have the risk of people starting copying that way of doing things in the ontologies that they implement!
mlefranc: I understand that one namespace implies one ontology
… LOV assumes this
mlefranc: We can show creativity in this. We're working with Ghislain on breaking the 1 - 1 relationship between namespaces and ontologies
… LOV will support one prefix for multiple ontologies
<mlefranc> I will contribute to LOV to do so, Talked with Ghislain about this early Jan
<ahaller2_> Option 1:
<mlefranc> +1
<roba> 0
<kerry> +1
<ahaller2_> 0
-1
<RaulGarciaCastro> +1
<Linda> -1
<joshlieberman> -1
<eparsons> _1
<eparsons> -1
<AndreaPerego> -1
<mlefranc> note Simon's vote for option 1 is: -1
<mlefranc> and danh just got disconnected ?
<ahaller2_> jano said 0 -1
<mlefranc> Jano said: -1 to 0. in case this is the chosen option, then +1 for unify = sosa
<ahaller2_> danh: +1
<ahaller2_> Option 5:
<ahaller2_> 0
<mlefranc> 0
-1
<Linda> +1
<roba> 0
<kerry> 0
<eparsons> 0
<RaulGarciaCastro> 0
<mlefranc> note Simon's vote for option 5 is: 0
<AndreaPerego> 0
(my -1 based on what's written in the wiki)
<ahaller2_> danh: 0
<roba> is it possible to tease out phil's issue here?
<ahaller2_> Option 8:
<kerry> -1
<ahaller2_> -1
<RaulGarciaCastro> -1
phila: My issue is the conneg one
<mlefranc> -1
<eparsons> -1
<Linda> -1
<roba> 0
0
<AndreaPerego> -1
<mlefranc> @phila, we agreed that conneg would be removed from option 5
<mlefranc> note Simon's vote for option 5 is: +1
<joshlieberman> +1 to 5, -1 to 8
<roba> yep - cannot get to axioms - thats all
Then I don't see how option 5 works mlefranc
<DanhLePhuoc> -1 for 8
<mlefranc> @phila, what do you mean "work" ? it works like skos and skos-xl for instance
<roba> yes option 1 and 5 cannot get axioms , 1 works if we abandin SOSA core and have one ontology
<Zakim> kerry, you wanted to suggest we drop option 8 off and recondier 1 and 5 -- t hey are very similar!
phila: If we get rid of weird conneg behaviour, then I'm probably OK with 5
<kerry> yes josh!
joshlieberman: It is true that without some sort of negotiation, there is no path from SOSA to the SSN extras - which is as it should be
ahaller2_: +1 to joshlieberman
<roba> yes josh - and thats a design decision we need to make with our eyes open
<ahaller2_> just removed the content negotiation sentence in Option 5
<ahaller2_> Option 1:
<ahaller2_> 0
<mlefranc> +1
<RaulGarciaCastro> +1
<Linda> -1
-1
<eparsons> -1
<roba> -1
<DanhLePhuoc> +1
<kerry> +1
<AndreaPerego> -1
<joshlieberman> -1
<mlefranc> Simon: -1
<ahaller2_> jano: -1 to 0
<ahaller2_> Option 5:
<ahaller2_> 0
<mlefranc> +1
+1
<eparsons> +1
<Linda> +1
<joshlieberman> +1
<RaulGarciaCastro> 0
<roba> +1
<DanhLePhuoc> 0
<mlefranc> oups --> 0
<AndreaPerego> +1
<kerry> 0 but really sorry to miss the chance to do much better
kerry: I'm curious what people who have yet to speak why they're concerned about option 1?
<mlefranc> (difficult to hear you linda)
Linda: I'm concerned that option 1 will confuse people. There are potential users of SOSA who want something simple.
… It's clear, it's simple
… It provides a simple core that people can use with its own namespace. People don't need to know about the more complex one
AndreaPerego: +1 to Linda. There needs to be a clear separation between the two vocabs. Linking the two would lead to confusion
<mlefranc> +1 for what kerry is just saying
kerry: To respond to that. If you're a SOSA user, and the SOSA file is separate, you'd never know about the extension
<roba> agree - but is you ask for unify:system you suddenly get a rich OWL ontology which looks nothing like unify:Platform
kerry: But in option 1, the complex knows about the simpler
kerry: The difference is how the extended relates to the simple
joshlieberman: This is another example of not the mechanism, it's what people do.
… If someone looks for terms with the SOSA prefix on the Web, they'll get a load of different terms
… As a technical matter, you are right, Kerry. But add humans and 5 wins (scribe paraphrase)
<ahaller2_> PROPOSED: Use the implementation in Option 5 for the integration of SOSA and SSN
+1
<eparsons> +1
<mlefranc> 0
<Linda> +1
<RaulGarciaCastro> 0
<joshlieberman> +1
<kerry> 0
<ahaller2_> 0
<AndreaPerego> +1
<DanhLePhuoc> 0
<roba> +1
Resolved: Use the implementation in Option 5 for the integration of SOSA and SSN
<kerry> [applause!]
joshlieberman: Maybe we can propose another resolution that we agree that the options for modularisation are unsatisfactory
<kerry> like that idea!
joshlieberman: Something to feel better about
ahaller2_: We can make that in the doc
… A direct consequence of not having a unified namespace, there's a long running issue around the SOSA name
<ahaller2_> "Sensor, Observation, Sample, and Actuator (SOSA) Core Ontology"
ahaller2_: [explaining SOSA name]
… I don't know if anyone has a better name, or if at that point in time, we should just continue with SOSA
kerry: My concern is around our explicit attempts to modularize SSN. Recently, I'm really happy that there is a simple core with a clean separation with the more complex vocabulary.
… Name matters for the document, for branding stuff.
… I think we want to capture that notion of a core and of extension.
<roba> would be nice ..
<RaulGarciaCastro> +1 for consistent naming
kerry: Consistent naming that would make it look not as 2 independent things would be good.
Phil: I agree with you, Kerry. SSN-lite would fine. SSN-core. SSN and SSN-extended would be good as well. I agree that branding is important. The existing names are new enough that they can be replaced without problem.
mlefranc: SOSA-core, SOSA-extended, would that work too?
kerry: That would work as well. SOSA-core and simply SOSA would be good as well. I don't like SOSA-extended very much.
<mlefranc> prefixes: sosa-core: for SOSA Core, and sosa: for SOSA
<joshlieberman> This is why the whole namespace mechanism is archaic.
<phila> phila: 'XL' might be a suffix for the full version?
<mlefranc> @josh, this is why option 1 ;-)
<phila> phila: (as in SKOS-XL)
ahaller2_: I do understand that there is a wide community for the SSN ontology. It's probably a problem to rename SSN. I would prefer to rename both though.
<Zakim> AndreaPerego, you wanted to note that is you rename SSN into SOSA this will be intuitively considered a different ontology
ahaller2_: The prefix could be ssn for the name SOSA extended, perhaps.
AndreaPerego: If I were a previous user of SSN and saw sosa, my impression would be that it would be different from the ontology I know. For branding, personally I would not change the acronym
<joshlieberman> Andrea makes a good point that this is a question of branding, not explicit identity or semantics.
mlefranc: On the other hand, it's easy to add a name in the spec to explain why we did not keep the SSN name. It would make it easy for us as well, as we would not have to redirect the old SSN ontology.
<ahaller2_> +1 for what maxime said
mlefranc: The semantics are changing, the name sosa illustrates the changes that occurred in the ontology.
kerry: I agree with Andrea. Keeping the branding of SSN is important. I appreciate Maxime's point as well, though, so won't vote against any of these options.
<mlefranc> so two options: option1 is sosa-core/sosa, and option2 is ssn-lite/ssn ?
eparsons: I don't think we got agreement right now.
<ahaller2_> can't hear phila
phila: Whatever is called, we can agree that it's called "thing-core", then "thing" for the extended version.
<kerry> +1
<mlefranc> +1
<RaulGarciaCastro> +1
<roba> do we want thing and thingxl or thing-core and thing?
<RaulGarciaCastro> :)
<phila> PROPOSED: That the 'two' ontologies share a common name with either prefix or suffix to distinguish, e.g. 'lite' or 'full'
<ahaller2_> 0
<roba> +1
<mlefranc> +1
<RaulGarciaCastro> +1
<phila> +1
<eparsons> +1
<AndreaPerego> +1
<Linda> +1
<kerry> +1
<mlefranc> * sosa-core or ssn-core will be yet another prefix that is cannot be registered in prefix.cc because this tool doesn't allow prefixes with '-' characters ;-)
Resolved: That the 'two' ontologies share a common name with either prefix or suffix to distinguish, e.g. 'lite' or 'full'
phila: OK, now on to the more contentious part.
<phila> PROPOSED: That the common name should be either SSN or SOSA (please state preference)
<eparsons> SSN
<ahaller2_> SOSA
<Linda> I'm neutral on this
<mlefranc> SOSA
<RaulGarciaCastro> SOSA
mlefranc: I think it's not a problem if we use hyphens, it's just that prefixes need to change with some tools.
<AndreaPerego> SSN
<joshlieberman> No preference
<kerry> SSN
<roba> SOSA - but not strongly
<mlefranc> * @ tidoust, to me it's the implementatino of prefix.cc that should be updated
phila: That seems inconclusive
<DanhLePhuoc> SOSA
<RaulGarciaCastro> Let’s vote for both and look for -1s
<roba> jano would be strong on this I think,
<ahaller2_> Jano would be SOSA, Simon I don't know
<mlefranc> I think Simon would also be in favour of SOSA
<mlefranc> he cares about 'sampling' being part of the name :-)
<phila> PROPOSED: That the base name of the ontologies is SOSA
<mlefranc> +1
<ahaller2_> +1
<RaulGarciaCastro> +1
<Linda> 0
<kerry> 0
<joshlieberman> Since it is a branding issue, maybe we can do a focus group?
<phila> 0
<AndreaPerego> 0
<eparsons> 0
<DanhLePhuoc> +1
<roba> 0
<ahaller2_> @joshlieberman if we get an extension of the working group, we can do focus groups ;-)
<phila> PROPOSED: That the base name of the ontologies is SSN
<phila> 0
<Linda> 0
<ahaller2_> 0
<RaulGarciaCastro> +0.5
<kerry> +1
<AndreaPerego> +1
<DanhLePhuoc> 0
<mlefranc> 0
<eparsons> +1
<roba> 0
<RaulGarciaCastro> To advance I can round it to 0
<kerry> yes to that!
phila: If the core was called SSN-lite, SSN-core, I think I would probably go for SSN. In other words, the new suffix to SSN handles the political issue that in some people's eyes, SSN was too complicated.
<eparsons> +1 to phila
phila: But I don't feel strongly enough about that to oppose renaming to SOSA though.
<RaulGarciaCastro> +1 to phila
eparsons: The value-add is to simplify SSN. My preference would be SSN-simple.
<roba> ssn-bigly-tremendous
<ahaller2_> maybe we postpone that issue?
eparsons: People coming from SSN would find SOSA otherwise, and be confused.
kerry: Should we go back and look at the suffix and then go back to the name?
eparsons: The actual name is more the issue
<kerry> thing-core, thing-lite, thing-full etc
<kerry> ...thing-simple
eparsons: My vote would be thing and thing-simple, with thing being SSN.
<roba> thing-terms\
<ahaller2_> I don't think that people care too much about core, lite, full or simple, but more the name
<mlefranc> thing-xs and thing-xl ?
<phila> phila: I'd say ssn-lite and ssn (maybe ssn-full) but I am not wedded to these
eparsons: We could spend all of our time talking about these branding issues.
Linda: In light of what you and Phil just said, I would vote +1 on SSN now.
… We are, in this WG, working to make it more simple.
mlefranc: I think it's a question that is sensitive enough that we cannot ignore the fact that Simon and Jano are not here.
<roba> agree with maxime
mlefranc: I would rather postpone to next week.
ahaller2_: Agree with Maxime. It would be unfair for them to resolve without them.
… I would also agree, given that no one has a strong opinion here, to postpone.
kerry: I'm ok with that, but we should record the opinion of people here who may not be attending an SSN meeting.
eparsons: Right, that's what minutes give us.
<phila> PROPOSED: That the SSN Sub Group takes up the naming issue, noting that the F2F participants have a slight preference for SSN
<ahaller2_> do it in a general SDW meeting
<eparsons> +1
<Linda> +1
<phila> +1
<roba> +1
<DanhLePhuoc> +1
<kerry> +1
<AndreaPerego> +1
<RaulGarciaCastro> +1 (but prefer in a general meeting)
<mlefranc> +1
<ahaller2_> +1 (prefer also in the SDW meeting)
<kerry> agree -- on a plenary agenda
<phila> PROPOSAL: That the SSN Sub Group takes up the naming issue, noting that the F2F participants have a slight preference for SSN, but the decision will be made in a plenary call
<eparsons> +1
<RaulGarciaCastro> +1
<Linda> +1
<kerry> +1
<phila> +1
<ahaller2_> +1
eparsons: Good point, Raul, maybe if the SSN sub group can bring the naming issue back to the group, that would be beneficial.
<mlefranc> +1
<ahaller2_> next plenary please
Resolved: That the SSN Sub Group takes up the naming issue, noting that the F2F Meeting Day 2 participants have a slight preference for SSN, but the decision will be made in a plenary call
<Zakim> kerry, you wanted to comment on agenda
kerry: We had planned for a vote on OWL-Time. Not sure if we can do that today. Lots of changes made to OWL-Time and I haven't had time to look closely at them. If we don't have Simon or Chris, what should we do?
eparsons: Agree we cannot do much in their absence.
… My sense would be not to do it, and break earlier if we can.
phila: Next, I'll talk about continuation of this work after this group
<ahaller2_> phila can you come closer to the mic, please
phila: Sending you the document that Scott has written. Not discussed at all at W3C so far, because we had hardly signed the MoU (still under review by our membership).
<Zakim> kerry, you wanted to also remind phil about ssn timeline topic that got skipped yesterday due to traffic.
phila: I expect to discuss this document with Denise and Scott some time today. Input from the group would be hopeful. Don't make the document public at this stage, though.
Phil: About timeline, we need to think about whether any of, or both, ontologies can make it to CR by June.
… There's a bunch of options on the table, but we basically have 2 months left.
<ahaller2_> @phila I am still optimistic about CR, there are not too many issues left
Phil: From my point of view, the chance of reaching that level for either of those is small, but I suggest discussing it.
[15mn break]
<phila> The jaws that bite, the claws that catch!
<phila> Beware the Jubjub bird, and shun
<phila> The frumious Bandersnatch!
<roba> oh frabjous day!
<ahaller2_> http://w3c.github.io/sdw/ssn/#SSNObservation
<mlefranc> I can give it a try
<ahaller2_> thanks mlefranc
kerry: minCardinality 0 suggests that you can relate this concept to another one using this property
… it's useful for documentation reasons
… although it conveys no semantics at all
… my proposal would be to keep it
RaulGarciaCastro: people that use the ontology might start doing the same in their own ontology
… is it the right way of documenting an ontology ?
… my proposal would be to remove these axioms
kerry: because we do not have domain/range, it's good to have some local trace that this property is a proeprty of observation
<ahaller2_> +1 to that this actually should help the user
kerry: to me using these axioms does more good than harm
<ahaller2_> mlefranc: proposes to use that in the comment of the property
mlefranc: I propose to move these meaningless axioms into the comments
… of the Observation class
RaulGarciaCastro: I won't fight for one or the other, at least the decision should be documented
ahaller2_; <summarizes what kerry, mlefranc, RaulGarciaCastro just said>
<ahaller2_> PROPOSED: Remove minCardinality 0 on ssn:qualityOfObservation ssn:observationResultTime ssn:observationSamplingTime on Observation and put them in comments of the properties
roba: do we have evidence of users of SSN that think this is usefull ?
kerry: the observationResultTime is used <missed the point>.. but I don't recall anyone complaining about them
… it's there so you use it, although it holds no semantics
+1
<Zakim> phila, you wanted to talk about profiles
phila: do you really need cardinality constraints in the spec, or can you move them in another profile ?
<Zakim> kerry, you wanted to answer phila
phila: in general, you can use relax or precise the semantics of ssn, which would define a new application profile
… refering to a new working group
kerry: this specific cardinality constraint is "at least zero", so that acts as:
… a. a faithful representation of the UML model that is represented here
… b. that's the only way of documenting an expectation of how the property should be used in the ontology
phila: why not put them in the comment ?
kerry: <explains historic reasons>
phila: as a developer, I may be frustrated to spend time implementing stuff that are actually useless
<phila> That's another good reason to leave out formal axioms - data bloat that just slows down the system, Danh, yes
<RaulGarciaCastro> agree with Danh
DanhLePhuoc: whatever you put in cardinality constraints, in practice, in 2 EU projects I am involved in, cardinality constraints slow the implementations
roba: is cardinality 0 equivalent to domainIncludes in SOSA ... ?
<ahaller2_> +1 for roba, schema:domainIncludes and schema:rangeIncludes
<ahaller2_> q/
<ahaller2_> PROPOSED: Remove minCardinality 0 on ssn:qualityOfObservation ssn:observationResultTime ssn:observationSamplingTime on Observation and put them in comments of the properties
<ahaller2_> 0
<kerry> 0
-1
<eparsons> 0
<roba> 0
<AndreaPerego> 0
" +1 if you write: and put them in comments of the Observation"
<DanhLePhuoc> +1
<RaulGarciaCastro> 0 (if also documenting the class)
<phila> +1
<ahaller2_> PROPOSED: Remove minCardinality 0 on ssn:qualityOfObservation ssn:observationResultTime ssn:observationSamplingTime on Observation and put them in comments of the properties and the Observation class (potentially using schema:DomainIncludes schema:rangeIncludes
+1
<ahaller2_> 0
<DanhLePhuoc> +1
<kerry> 0
<RaulGarciaCastro> +1 (-1 to schema properties in SSN)
<phila> 0
<eparsons> 0
<roba> +1
<AndreaPerego> 0
Resolved: PROPOSED: Remove minCardinality 0 on ssn:qualityOfObservation ssn:observationResultTime ssn:observationSamplingTime on Observation and put them in comments of the properties and the Observation class
+1
Resolved: Remove minCardinality 0 on ssn:qualityOfObservation ssn:observationResultTime ssn:observationSamplingTime on Observation and put them in comments of the properties and the Observation class
<RaulGarciaCastro> totally agree
<ahaller2_> mlefranc: remove mincardinalities of 1 in all cases
mlefranc: maybe using someValuesFrom instead can help SSN become valid OWL 2 EL
kerry: not wanting to vote on a proposal to change these axioms in SSN regardless of the precise locations
… I strongly believe we can fall back to OWL 2 EL anyways
<ahaller2_> The property ssn:observedProperty must be 1 http://www.w3.org/ns/ssn/Property 1 time(s)
ahaller2_: the only occurence of maxCardinality is on Obseravtion
<ahaller2_> https://github.com/w3c/sdw/blob/gh-pages/ssn/ssn_separated/ssn.ttl
ahaller2_: let's have a quick look on where it occurs
<ahaller2_> owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
[ rdf:type owl:Restriction ; owl:onProperty sosa:featureOfInterest ; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ; owl:onClass sosa:FeatureOfInterest ] , [ rdf:type owl:Restriction ; owl:onProperty sosa:isObservedBy ;
ahaller2_: 4 places: sosa:featureOfInterest sosa:isObservedBy ssn:observedProperty ssn:sensingMethodUsed
kerry: that's O&M's UML model to OWL conversino
* (I corrected the minutes)
RaulGarciaCastro: with these strong restrictions we are forcing people to instantiate the Sensing class (for example), which most users do not do
<ahaller2_> +1 to RaulGarciaCastro
roba: open world assumption makes it interesting to use axioms to implicitly say for instance; the class of observations that observed this exact foi,..
… <missed the rest, sorry>
kerry: it's important to allow for some classes to not be instantiated .. anyways, a reasoner can infer that "some instance" exists
… the max cardinality remains important
<roba> ok - sounds like its a good thing to leave in then - its usefl semantics
<roba> there is no "feature of interest" class really...
<roba> we can infer that a feature is acting as a feature of interest becuase it is related to an observation
kerry: can we maybe just say: maxCardinality 1 instead of qualifiedCardinality 1 ?
roba: we should maybe ask to the list for the implications of each option ?
<Zakim> kerry, you wanted to ask why we want to change it?
<ahaller2_> +1 to mlefranc
<ahaller2_> mlefranc: what if a property is a FeatureOfInterest
mlefranc: what if a property is also a property of a featureOfInterest
ahaller2_: mlefranc will post an email to the list first
<roba> +1
<phila> issue-153?
<trackbot> issue-153 -- reconsider role of device in ssn as a result of the changes to platform required for sosa -- raised
<trackbot> http://www.w3.org/2015/spatial/track/issues/153
ahaller2_: role of device class on SSN: sensor can be attached to sensor and is then itself a device.. need to discuss about the implications
<kerry> prefer to break but can go on too
<eparsons> Delft will return at 13:45 to talk about what happens next...
<RaulGarciaCastro> prefer to break for lunch
<RaulGarciaCastro> does not seem a “fast" issue
<phila> [Adjourned]
* @ armin, I think we could also solve quickly the issue about Measurement and Operating property, that may apply to actuators...talk
<ahaller2_> @mlefranc i had this issue on my list too, yes, but it seems we can't do any issue anymore today. will postpone to next week
Phil: The wording of the document I sent around was written by Scott
… From an OGC perspective, the TC would setup a subcommittee which would be a permanent group. Modelled after the ISO TC2 11 group.
… From a W3C perspective, this would be an Interest Group (IG).
… The group would not be constitued to create standards.
… It could publish notes, use cases, etc. but no standards.
… The question is: is that valuable? Can we think of things that this group could do right away?
eparsons: My concern would be that, as constitued, it would be a group that discusses issues and identified gaps where standards could be useful, and can do the incubation. My concern is that these groups often end up being a talking shop.
<roba> +1 ed
eparsons: The danger would be that we just sit down 3 times a year, have a nice talk, and be done with that.
Linda: I also do not want a talking shop. What would happen when we want a standard? Would it be easy to create a group?
phila: W3C IG can write a charter for a new WG. Yes, it would be easy for that JWOC group to write a charter. It then needs to go through the Membership for review.
… So it does make it easier, but does not change the rules either to create a WG.
ClemensPortele: The group would not ask for presentations. The scope of the group should be clear.
… This should be the place where people agree about "is it a W3C charter?", "is it an OGC charter?", "is it a joint charter?"
… I think there is value, but we need a clear standing agenda, and not presentations of relevant stuff
roba: The issue would be what you need in JWOC to identify gaps. It's been useful in the SDW WG to discuss and identify technical gaps.
… We've done a great job at this. I'm not 100% convinced that it's going to transition to another group.
billroberts: It sounds like a good idea to me. I can see a useful role for the JWOC. The SDW WG proves it's useful to have joint works. Coordination is good, so setting up some group to make that possible seems a useful thing to have.
kerry: Are we expecting JWOC to incubate ideas or are expecting others to make proposals?
eparsons: That's a good point.
… The two communities themselves will have ideas.
… JWOC would have coordination role, deciding what's the best place to develop something.
… But I'm not sure you can justify having it being the incubator.
kerry: So I think there needs to be something more explicit for making decisions, path for influence.
ClemensPortele: The proposal says that every WG chair in both organizations are part of the group, with voting rights.
… We need this kind of mechanism for Scott to bless a topic as related to spatial data on the web, and to be discussed in JWOC. Similar mechanism at W3C.
… Everyone should have the possibility to raise such an issue.
phila: JWOC is only concerned by either doing work that is joint, or proposing work that is joint.
… When a topic does not need to be done as joint work, it should pass outside of scope for JWOC.
… In terms of voting rights, I'm trying to phrase it in a way that be both open and balanced. Other WGs at W3C that come to mind: Geolocation, Web of Things, etc.
… At each charter renewal, there should be a clear list of things that need to be done.
… The overlap between data on the web, spatial data, etc. is enormous.
eparsons: Would there be a way for JWOC to take on deliverables such as the ones we've been working on, meaning non-normative documents.
… That would scope things down.
phila: I would love to see the Coverage work continue for instance, with the question of whether JWOC could help bring that to a state where standardization could be done.
… Statistical data on the web best practices could be an example.
<roba> QB4ST jneeds to be integreated with OLAP models - how dikmensions are "rolled up" in spatio-temporal contexts)
phila: We could identify specific areas that should be put in the charter.
roba: [mentioning QB4ST, what functions exist to convert day month year]
… Spatial use cases that use cube would provide a perfect example of why a joint work could be useful.
eparsons: Playing devil's advocates. If JWOC had existed 10 years ago, you could argue that most of the work done by OGC would have better been done as Web specifications.
… Probably a bigger problem for OGC than W3C. Lots of things are not spatial enough to be a spatial spec.
roba: I've been at OGC for a long time and struggled with that for a long time.
… Spatial use cases have been running up against the architecture
… The nature of spatial data is that it naturally fits within distributed systems. Most of the patterns of distributed systems are spatial by definition.
… I think we'd be a lot further ahead if we had started the work a long time ago.
Linda: What if there is some thing that comes up that needs standardization and JWOC says "W3C should do it", but OGC members do not contribute§?
phila: Then it doesn't happen. We can only do what our members tell us to do and are willing to do.
… If the JWOC were to say, we need to create a WG to work that, then my instinct tells me that all WG participants will need to be part of both organizations.
… One of the member organizations that was member of both left, another did not contribute, etc.
… We want to encourage membership, which may make the proposal impractical.
billroberts: Members would choose the cheaper, of course. It's important to keep self-funded contributors engaged as well.
kerry: I think that's true. We have had people looking at options. I wonder if we might think of joint membership fees longer term, perhaps with some responsibility.
<roba> i was thinking along the same lines
phila: We did merge with IDPF recently, but that's not going to work here because we serve different communities.
… Now, there's another mechanism on W3C side: a Business Group (BG), which you can join for a restricted fee.
ClemensPortele: Nobody joins just for JWOC. No one will join OGC if interested in W3C.
… Membership fees at W3C are a substantive amount of money, making it a difficult case to make. It would be good to have a mechanism for companies to join the works that they are interested in.
phila: The BG fees won't allow you to join a WG
ClemensPortele: making it a bad deal overall.
eparsons: Maybe some elements in this space could be funded by research projects.
ahaller2_: There is an introductory industry membership at W3C for large companies that allow them to join an IG. There's nothing similar for small companies.
… You could imagine a similar mechanism for a couple of years.
phila: If JWOC is free, and it creates a WG, would you agree to pay 2K?
ClemensPortele: Depends on the group
eparsons: If the client is willing to pay. We cannot really tell whether a group is going to be worth a particular amount today.
<phila> Potential work items for JWOC
<phila> - Continue supporting development of CoverageJSON
<phila> - Continue development of QB4ST
<phila> - Continue development of EO-QB
<phila> - Statistical Data on the Web BPs
phila: To run back a bit, the general feedback is that there is value in the JWOC proposal if it has specific goals.
… I listed 4 (see above)
roba: I actually think the nature of EO-QB is more around best practices. I would tend to merge QB4ST and EO-QB as one work item.
… I also think that the SSN stuff is going to be specialization of SSN for specific domains. Classes of sensors which relate to the hot topic of the day.
… Applications of SSN.
ClemensPortele: One question is would small updates to the best practices that we have today be included? Minor updates to keep the document up-to-date?
<roba> +1 to that
phila: Yes, the JWOC could do that directly.
Linda: We also mentioned the spatial ontology before. To be considered.
… Also GeoDCAT.
phila: That actually raises an issue. If you want an extension to DCAT as opposed to GeoDCAT-AP, then the new WG that I'm currently proposing can take care of that.
… JWOC would be directly well positioned to influence discussions in both organizations. An OGC SWIG would be well advised to take some advice from JWOC on web related stuff.
AndreaPerego: There will be a meeting tomorrow of a group looking at DCAT for geospatial data. There is a risk of overlap.
kerry: I used to follow the Research Data Alliance, who decided to make their own standards. I'm wondering whether taking this concept to them to get feedback and see if they would be willing to bring their standards if JWOC existed could be useful.
Linda: Another thing around topical sensors. Already mentioned. That seems worth investigating.
<Zakim> phila, you wanted to talk about ANDS, RDA, etc.
roba: [relationship with RDA]
phila: When RDA started, I missed the first plenary and went to the following ones. Trying to improve relationships here. They serve a different community. That does not surprise me that they came up with their own standards.
[discussion about RDA]
eparsons: Summary: there's value in JWOC as a coordination point, and also there is on-going work that this group could take on. These are both useful things.
tidoust: I note the current proposal is not very explicit about JWOC doing incubation or spec work. Could be worth emphasizing.
<phila> Potential work items for JWOC
<phila> - Continue supporting development of CoverageJSON
<phila> - Continue development of QB4ST
<phila> - Continue development of EO-QB
<phila> - Statistical Data on the Web BPs
<phila> - Update SDW-BP as necessary
<phila> - Common spatial ontology
<phila> - GeoDCAT
<phila> - Generic Sensor API
<roba> Applications of SSN?
<phila> Potential work items for JWOC
<phila> - Continue supporting development of CoverageJSON
<phila> - Continue development of QB4ST
<phila> - Continue development of EO-QB
<phila> - Statistical Data on the Web BPs
<phila> - Update SDW-BP as necessary
<roba> and i'd include EO as a use case for QB4ST
<phila> - Common spatial ontology
<phila> - GeoDCAT
<phila> - Generic Sensor API
<phila> - SSN Applications
<phila> - Nieuhaven narrative
<phila> tidoust: Patent commitments would be important
<phila> tidoust: The Web and TV IG, there are probs with patent commitment
<phila> ...Not in other IGs
<phila> phila: I'd assume we're talking about royalty free outputs.
<phila> RDA Plenary Barcelona
AndreaPerego: The RDA plenary will be in a couple of weeks in Barcelona. It may be worth doing a presentation in the geospatial group
… Maybe there are other opportunities. Poster, keynote.
roba: I don't know enough about the plenary.
kerry: I think it's a good idea, but who would be going?
roba: Simon might be going.
eparsons: We do need to advertize the best practices. In a future plenary call, we should discuss how we do that.
kerry: The WWW conference is in Australia in a couple of weeks. A few of us will be presenting, including Armin, Byron and myself.
<ahaller2_> https://www.w3.org/2017/WWW26/Overview.html
Roba: I'll be presenting stuff as well.
eparsons: Thanks, any other points before we conclude?
<RaulGarciaCastro> Bye
<ahaller2_> bye
<roba> Actually Nick Car will be reporting on state of play witrh ref to some stuff
<kerry> bye!