See also: IRC log
<eparsons> https://www.w3.org/2015/spatial/wiki/Agenda_F2F3
<kerry> scribe: BartvanLeeuwen
<kerry> scribeNick BartvanLeeuwen
<kerry> scribeNick: BartvanLeeuwen
<phila> agenda: https://www.w3.org/2015/spatial/wiki/Agenda_F2F3
<phila> chair; Ed
<phila> chair: Ed
<kerry> https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisation_topic
kerry: 1st thing,
modularisation
... this is the most indemand thing, we had a discussion about
this already
... can we do our FPWD about this
... the task of modularizing SSN is a significant thing to do,
to get feedback
jtandy: I agree, that breaking it up in small chunks is making the vocabulary easier to use.
ahaller: will DULC be a module
kerry: it will be external, a vocabulary which imports SSN and DULC
ahaller2: shouldn't we just have one vocabuarly, and a lightweight IOT deliverable
kerry: I don't have big objection
that, but probably a lot of other have
... others might argue that SSN including DOLCE is too
difficult
frans: I wonder what the modularization is about, it seem to split it in several files
<ChrisLittle> preseent+ ChrisLittle
frans: how does that influence usability, it could be a barrier to have different namespaces for different properties
kerry: I'm inclined to agree with you
frans: which problem is being solved by modularization?
<ahaller2> agree too, too many modules may prevent usage
DanhLePhuoc: do we do modularization on base of previous work on SSN, or on newly chartered requirements
kerry: if we don't want to split
SSN and take out DOLCE, I don't have a problem with that, we do
have new requirements which we could do a new vocabulary
... I've put something on the list which is something like a
'profile' which a reasoner could put back together
... on of the other calls is about lightweight IOT
vocabulary
... I'd like to relate that to SSN
... I'm not pushing the idea we need to split up SSN
<Zakim> jtandy, you wanted to ask how / if modularisation will help _users_ of the vocabulary? other than providing it in smaller conceptual chunks
jtandy: I'm thinking why I said
modularization is a good thing, what are the key benefits of
modularization here? Is this going to work with OWL
ontology
... are we making it easier for users, or does it introduce
problems with multiple namespaces
... is it easier to maintain. Key question what is it what we
want to achieve ?
DanhLePhuoc: I have some answer
why we might need to split up, if you have small devices we
need to have a option to build a small device we need to be
able to load a subset of the ontology on the reasoner.
... it is also a strong requirement in wht WOT group, how can
we do processing on the micro controler
<jtandy> [wow - I hadn't realised that @DanhLePhuoc & others was intending to load reasoners onto embedded devices!]
frans: I wonder how the usage of ontologies on the devices will work, if I have a array of devices do I just implement SSN, or do I subset it.
<Zakim> phila, you wanted to talk about SHACL and IoT Lite
phila: in a seperate domain I
keep comming up into application profiles, which puts
wonderfull ideas of ontologies in something practical one can
use.
... what is in my head, SSN is being put forward as a REC,
including modularization you talked about, parallel to that we
publish a NOTE which is already written, IOT-Light a member
submission
... it fits in this group, and the internet of things interest
group
... if the group agrees we could jointly review this submission
and publish this jointly
... we could also publish a machine readable SHACL which
represent the profile
<jtandy> [SHACL: https://www.w3.org/TR/shacl/]
eparsons: with you proposal, is there any sequencing needed ?
phila: no, NOTEs are not
normative
... if we do decide to do this, we have no idea what that means
to the OGC/W3C publising scheme
eparsons: its a different domain in OGC
phila: its interesting to see how this needs to be processed
<jtandy> [a good job that Scott S is our rep from OGC :-) ]
kerry: steve liang, the sensors things person, did show up on our meetings.
<phila> SHACL
<phila> IoT Lite Ontology
kerry: I posted on the list how to create a extraction of SSN
DanhLePhuoc: regarding the joined
forced the WOT I talked to people in WOT IG about the joined
work
... we have large project with 13 partners about IOT , we have
a strong will for standarisation
... it is a good idea to have joined force, the WOT will go for
a working group bringing a lot of industry.
<ahaller2> +1 to collaborate with WOT on the Lite ontology
eparsons: is this working group thinking about publishing SSN and do a IOT light note, or still do modularization of SSN
kerry: I'm happy with the plan phila put forward, a profile of SSN sounds like a smart thing to do, not sure how SHACL fits in
aharth: I think modularization has a couple of benefits, it keeps modeling small, lowering the learning curve
<frans> I can see how modularization helps the ontology developers. If users only use profiles the modularization won't bother them
aharth: it allows to reuse certain parts of existing vocabularies, e.g. coverage of SDW, units vocab by NASA or Data-Cube
<Zakim> phila, you wanted to separate SHACL and profile issues
aharth: this could be the benifit of reuse instead of inventing your own.
<kerry> +q
<kerry> SHACL uses RDF and RDFS vocabulary (in particular rdf:type, rdfs:Class, rdfs:subClassOf, rdf:Property, rdf:List, rdf:langLiteral, and rdfs:Resource) and notions (notably classes, instances, and subclasses). However, SHACL does not always use this vocabulary or these notions in exactly the way that they are formally defined in RDF and RDFS [rdf11-mt].
phila: a Profile is a document describing the profile, doesn't have to contain SHACL
kerry: I don't like what I see from the beginning of the SHACL spec
<ahaller2> kerry point to the github
<kerry> https://lists.w3.org/Archives/Public/public-ssn-cg/2012Jun/0000.html
kerry: the charter mentions modularisation in particular
<ahaller2> https://github.com/AGLDWG/TR/blob/master/ontology
kerry: I did a sketch of what is written in the email
<kerry> https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisation_topic
kerry: yellow arrows are
imports
... The design pattern on the top is about how sensors work,
but not really usefull
... it imports DOLCE on the right
... the left imports the sensor descriptions
<jtandy> [BTW: @kerry is describing this picture: https://www.w3.org/2015/spatial/wiki/File:Ssn_modular.png]
kerry: SSN has problems without DOLCE, I started with modules, but needed DOLCE in the end
<kerry> https://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/images/OntStructure-Overview.jpg
<Zakim> jtandy, you wanted to ask about O&M and sampling features
jtandy: <wrongtime> one of
the things we wanted to do is to bind in observations/
measurements from the OGC in SSN, do we need to mention that in
the FPWD </wrongtime>
... does modularisation allow blending in
observations/measurments form OGC
kerry: I think this would blend
in via import with modularization
... there are allignment issues
jtandy: Simon recently published something on observations-light and measurements-light
Linda: without knowing the details, I did see some work on using a profile instead of DOLCE
<jtandy> [Simon = Simon Cox]
Linda: without knowing the details, I did see some work on using a PROV-O instead of DOLCE
<Linda> http://www.slideshare.net/drshorthair/ontology-alignment-is-provo-good-enough
kerry: a SSN alignment with
PROV-O is publised a while ago
... I don't see where DOLCE and PROV-O are alternatives
ahaller2: from the original SSN
the modularization is imho a bit to fine grained
... I think if we modularize DOLCE so that we can load it
seperatly
<kerry> http://ceur-ws.org/Vol-1401/paper-05.pdf
kerry: I'm inclined to
agree
... the number of namespace you need to remember is large, the
cost of the modularization is high
<ahaller2> ahaller2: we may want to consider modules for O&M and Actuators, though, i.e. the new stuff we want to add
eparsons: the argument for modularization is about replacing certain parts which might not be of your liking
frans: modularization is about being able to replace parts
kerry: I disagree, there is
universal agreement that DOLCE should not be tied to much to
SSN as it is now
... so pull out DOLCE
... there is potential use of including others e.g. PROV-O and
Data-Cube
<aharth> qudt has units and measurements: http://www.qudt.org/
kerry: other then DOLCE there is nothing we should take away
<ahaller2> +1 to modularise DOLCE out
DanhLePhuoc: I could agree with
kerry that multiple namespaces is a terrible idea to work with
sensors
... just splitting the SSN in smaller pieces is not something
wel should do
ahaller2: in terms on the namespaces we could use slashes in stead of hash so the main part of the namespace stays the same
<frans> If users only use a profile they only have a single namespace, don't they?
<aharth> @prefix ssn: <http://ssn.example.org/schema/> .
<aharth> and then multiple files: http://ssn.example.org/schema/dolce.rdf, http://ssn.example.org/schema/core.rdf and
<aharth> so on
<DanhLePhuoc> +1 for associate namespace with a profile
ahaller2: this will not solve that DOLCE is part of SSN so it needs to be imported anyway
<kerry> propose: for modularisation we work with michael's proposal (but remove dul and replace with native appropriately) and serve it using /uris and redirects as sugested by Armin
<phila> PROPOSED: for modularisation we work with michael's proposal (but remove dul and replace with native appropriately) and serve it using /uris and redirects as suggested by Armin
<eparsons> +1
<aharth> +1
+1
<AndreaPerego> +!
<AndreaPerego> +1
<ahaller2> +1
<jtandy> +1 ... seems fair, I'm no expert tho
<kerry> +1
<DanhLePhuoc> +1
<Linda> +1
RESOLUTION: for modularisation we work with michael's proposal (but remove dul and replace with native appropriately) and serve it using /uris and redirects as suggested by Armin
<LarsG> +1
ahaller2: on which infrastructure do we do that?
phila: that was my question, it can be done on w3/NS space
<phila> ==PAUSE==
<ChrisLittle> Thanks for scribe Bart
<eparsons> Scribe : billroberts
kerry: are there any other serious proposals on the table
kerry thanks Bart for rotating her picture
no proposals in the meeting room for other SSN modularisation approaches
next on agenda is: Armin's proposal for collaborative editing
<kerry> https://www.w3.org/2015/spatial/wiki/SSN_Tasks
ahaller2: has reviewed
predictability of tool behaviour when working with ontologies
and how that might work with Github
... with imported ontologies, Protege is unpredictable in terms
of serialisation, which would cause problems if storing the
output in Github
ahaller2: web-protege looks
promising as it has the main features that people will
want
... there is a widget where you can type in axioms
directly
... Vocol requires typing turtle, so Armin would prefer
Webprotege
... TopBraid has predictable serialisation so would work well
with Github
... Webprotege has advantages for collaborative working as it
is software as a service
kerry: if you use this editing approach (line based editing in Webprotege), do you lose the Protege advantages of keeping you in OWL-DL
ahaller2: it claims full OWL2 support but documentation is sparse so would need to check
<Zakim> jtandy, you wanted to ask if web protege = http://webprotege.stanford.edu ... is there a better link?
jtandy: is the above link the correct one?
ahaller2: that is the correct link
<jtandy> billroberts: how far are you planning to go with the OWLy parts (axioms) in addition to the classes and properties?
<jtandy> ... for just classes and properties I use a text editor- but this doesn't scale to big ontologies
kerry: the ontology already contains things beyond simple classes and properties, for example role compositions and multiple inheritance
so it's already complex enough that tool support is likely to be needed
kerry: will Webprotege be sufficient to support those features?
ahaller2, DanhLePhuoc - discussion of whether RDFS is useful/appropriate - easy and efficient though limited capabilities. Is it enough?
kerry: good idea, is it possible to add an RDFS view of the ontology? could be another module, similar to IoT-Lite
ahaller2: "SSN-Lite" might be effectively another module
kerry: don't want to take existing things out of SSN, because it might be already in use by the user base
DanhLePhuoc: we'll need to consider complexity of processing
kerry: bringing discussion back
to the question of collaborative tools
... only feasible choice appears to be Webprotege
ahaller2: alternative: just put it on Github and people can use their own choice of tools, as long as they check the serialisation
kerry: would be easy to break the
ontology, using that appraoch
... does Webprotege support versioning?
ahaller2: not sure of details, would need to investigate
kerry: could we use Github diff to determine changes?
<Zakim> jtandy, you wanted to ask @phila what his other teams do?
ahaller2: webprotege manages changes internally, but we can't use git with it
jtandy: what are other working groups using for developing vocabs?
<frans> a canonical serialization was mentioned once?
phila: there has been much
discussion of this. No standard tool is available at W3C
... DWBP - ontology developed as a diagram and phila manually
created the Turtle
... in most other groups it has not been collaborative.
Collaboration makes it hard
... wishes there was a better tool available
ChrisLittle: wikipedia notes
200,000 users for Protege "highly recommended, most used
ontology tool"
... sounds a good reason for choosing Protege
jtandy: challenge is collaboration versus desktop tool
kerry: so only choice appears to
be WebProtege
... there was a question on serialisation tools. Using those is
difficult
... vote needed?
eparsons: no
<ahaller2> i have already created a project on webprotege
<ahaller2> http://webprotege.stanford.edu/#Edit:projectId=dc983c6a-c144-4d5a-a2a2-1f8d25d1ad54
Decision made: use Webprotege
RESOLUTION: The SSN editors will use Web Protege as the collaborative editing tool
discussion of access to the collaborative tool
kerry: ok for people to see work in progress, just want to control editing rights
anyone have a link to the task list?
kerry: reviews task list
<Linda> https://www.w3.org/2015/spatial/wiki/SSN_Tasks
kerry: volunteers?
<DanhLePhuoc> I can do 3.
<phila> DanhLePhuoc++
ahaller2 will do 1.1 on WebProtege
kerry will do 1.2
<phila> ahaller2++
<ahaller2> ahaller2 helps with 1.2 too
DanhLePhuoc volunteers for 1.3, to be reviewed by kerry
<phila> ACTION: DanhLePhuoc to Reconsider O&M alignment (see O&Mlite) - as alternative to DUL [recorded in http://www.w3.org/2016/02/09-sdw-minutes.html#action01]
<trackbot> Error finding 'DanhLePhuoc'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<phila> ACTION: Phuoc to Reconsider O&M alignment (see O&Mlite) - as alternative to DUL [recorded in http://www.w3.org/2016/02/09-sdw-minutes.html#action02]
<trackbot> Error finding 'Phuoc'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<phila> ACTION: Danh to Reconsider O&M alignment (see O&Mlite) - as alternative to DUL [recorded in http://www.w3.org/2016/02/09-sdw-minutes.html#action03]
<trackbot> Created ACTION-139 - Reconsider o&m alignment (see o&mlite) - as alternative to dul [on Danh Le Phuoc - due 2016-02-16].
<phila> ACTION: Haller to clearly separate observation, sensor, and deployment parts of SSN [recorded in http://www.w3.org/2016/02/09-sdw-minutes.html#action04]
<trackbot> Created ACTION-140 - Clearly separate observation, sensor, and deployment parts of ssn [on Armin Haller - due 2016-02-16].
<phila> ACTION: kerry to disentangle SSN from DUL (this may require adding things to SSN that are needed from DUL) [recorded in http://www.w3.org/2016/02/09-sdw-minutes.html#action05]
<trackbot> Created ACTION-141 - Disentangle ssn from dul (this may require adding things to ssn that are needed from dul) [on Kerry Taylor - due 2016-02-16].
kerry: leave task 2 (align with
Prov-O) until the previous tasks have been completed as there
is a dependency
... ACTION-140 has already been done?
<phila> action-140?
<trackbot> action-140 -- Armin Haller to Clearly separate observation, sensor, and deployment parts of ssn -- due 2016-02-16 -- OPEN
<trackbot> http://www.w3.org/2015/spatial/track/actions/140
ahaller2: Michael's
modularisation is too fine grained, so it does need further
thinking
... will create a WebProtege file that separates DOLCE and
SSN
... is happy with action 140
kerry: that's enough for now.
DanhLePhuoc will review previous work for aligning RDF Data Cube with SSN.
DanhLePhuoc: requires first draft of modularisation
<eparsons> action Danh will review previous work for aligning RDF Data Cube with SSN
<trackbot> Created ACTION-142 - Will review previous work for aligning rdf data cube with ssn [on Danh Le Phuoc - due 2016-02-16].
eparsons: that's the end of items scheduled for this morning
kerry: we've set up initial actions around modularisation and removal of DUL, perhaps incorporating data cube context into SSN in a better way. Do you think that is enough for a first public working draft? or do we also need to address use cases, wishlist, O&M etc
phila: is that enough for someone
outside to read the document and understand what you are doing
and make suggestions
... enough to show people the direction you are heading in,
then it's enough for a first public working draft
kerry: thinks that would be about 2 months away. Would that be ok?
sorry!
typo
eparsons: soon would be good
kerry: plan for FPWD is 9 April
RESOLUTION: Target date for FPWD of SSN is 9 April (ish)
eparson: thanks kerry. End of SSN discussion
eparsons: there is an hour of discussion time available. topics?
BartvanLeeuwen: question on terminology. Use of 'GIS' and 'SDI'
eparsons: thinks of GIS as the tool to manage spatial content
<jtandy> see definitions in BP doc: http://w3c.github.io/sdw/bp/
eparsons: once you have lots of data you want to publish, that's when you move to SDI
<jtandy> GIS: Geographic information system or geographical information system, a system designed to capture, store, manipulate, analyze, manage, and present all types of spatial or geographical data. (ref. Geographic information system)
<jtandy> SDI: Spatial Data Infrastructure, a data infrastructure implementing a framework of geographic data, metadata, users and tools that are interactively connected in order to use spatial data in an efficient and flexible way. (ref. Spatial Data Infrastructure (SDI))
eparsons: so expected that SDI is discussed much more than GIS in SDWWG context
ChristLittle: desire to expose the details of the data on the web. How do you get 'inside' the GIS in a web context
eparsons: make distinction bewteen private internal view and a public external view - maybe a subset, maybe with extra metadata
jtandy: we have definitions in the BP glossary. Maybe they could be improved, but we have them (see Appendix D)
BartvanLeeuwen: reason would be to help people who think of themselves as GIS experts to understand what in the BP is relevant for them
eparsons: sharing my GIS with someone else might be a new use case
BartvanLeeuwen: might just want to share a shapefile with someone. Don't really want to set up a full SDI for that
frans: maybe SDWWG will offer a simpler alternative to sharing shapefiles for exchanging this kind of info
<Zakim> kerry, you wanted to talk about glossary
eparsons: shuold describe simple sharing of info in our narrative
kerry: early on we had a partial
glossary, some of it copied from Point of Interest working
group, and ISO documents
... consistency of BP glossary with that other list?
would be good to be consistent across deliverables
<kerry> https://www.w3.org/2015/spatial/wiki/Glossary_of_terms
kerry: eg we have more than on definition of coverage
<frans> I like the idea of having a shared glossary. I think it is needed to reach different audiences
eparsons: agrees. Action on editor of every document to ensure consistency
jtandy: Github issue 212 to address this for BP
<jtandy> see https://github.com/w3c/sdw/issues/212
frans: there is an online
glossary and we could link to those definitions
... could turn simple words into links to the glossary
eparsons: it's a working document,not a separate deliverable
frans: should be a public glossary
eparsons: yes useful, but not required by the charter
jtandy: respec has some automatic tools to link to glossary within the same document
frans: replicate a shared glossary to each document?
jtandy: but you might get lots of terms not relevant for that document
<Linda> scribe: Linda
wiki page can be internal glossary which could be partially duplicated to different documents
<jtandy> scribenick: Linda
kerry: the docs should each have their own glossary internally, and against having glossary as separate deliverable. But we need to be consistent.
The wiki glossary should help with that.
scribe: definition clashes should be addressed when needed by editors
ed: agrees
eparsons: agrees and good point brought up by BartvanLeeuwen
frans: is this a new action for
the UCR editors?
... it has no glossary section now
eparsons: it's up to you to have one or not
<Zakim> jtandy, you wanted to suggest looking at public comments
jtandy: let's take a look at the public comments of the SDW BP first draft
<jtandy> https://lists.w3.org/Archives/Public/public-sdw-comments/2016Feb/0021.html
jtandy: Rob Atkinson had a
comment that needs some unpicking
... it's about the structure of the doc which is lacking (just
a long list of BPs)
<jtandy> https://lists.w3.org/Archives/Public/public-sdw-comments/2016Feb/0019.html
jtandy: another one is from a 'Bergi' do we know him?
BartvanLeeuwen: I encouraged him
jtandy: we could also look at his comments
eparsons: lets look at Robs
comment first
... agrees with structure comment
... how much will introducing narrative around emergency
response help in solving this?
BartvanLeeuwen: agrees that
structure is currently missing
... has funding to work on emergency response narrative
jtandy: currently the BPs are
grouped by theme, but it's not an easy road in
... the first BP will probably remain first
... agree that more structure is needed
... a pathway into the doc is needed for different user
groups
... have the BPs in order of sequence of steps to take
... the data on the web BP people have tried to use a common
theme for their examples as well
... we could use the emergency response theme in example
snippets in the BPs, and have a longer narrative of the ER
theme in an appendix.
eparsons: makes sense
jtandy: maybe have two main
sections:
... one for web content people, one for data publishers.
eparsons: one group is actors who
already have GIS systems and another group is people who use
data on the web. Both involved in the same scenarios.
... but coming from different directions.
frans: I think their are more
audiences than two.
... the BP could be seen as a data cube. Different user groups
need different information from the doc.
... a narrative requires reading the doc from top to bottom. We
should allow people to pick the information they need out of it
without doing that.
... so self contained sections / modules needed
... not too many links from sections to other sections.
eparsons: raises a fundamental
point: the narrative could be a completely separate doc.
... the BP itself is then more a reference doc.
... the narrative would point to the BP relevant sections
... maybe we could use the event tomorrow where we have 'normal
people' to ask them what would be the best way in for them.
jtandy: this is certainly one of the questions to ask them
BartvanLeeuwen: the DW BP now
asks a lot from the reader.
... not sure if suggestions so far help readers
jtandy: Rob's suggestion is to add a section that explains the document is not prescribing one way of doing things. We should do this.
eparsons: but there's a balance,
we're also helping people pick the right approach, not just
providing a menu.
... to be useful we do need to make recommendations
jtandy: Rob gives four different options which are too detailed to unpick here.
eparsons: they are fair comments and not surprising to us
jtandy: working through the ER
narrative might help us illustrate in our own minds how it will
actually work. This will help us describe it.
... Geonovum testbed results will hopefully help us.
action jtandy to respond to Rob Atkinson's comments
<trackbot> Created ACTION-143 - Respond to rob atkinson's comments [on Jeremy Tandy - due 2016-02-16].
BartvanLeeuwen: let's talk about Bergi's comments
GeoJSON and JSON-LD conflict in the way they are constructed.
BartvanLeeuwen: has been
discussed a lot, conclusion is it cannot be solved
... if you add LD to GeoJSON it will not work in current
toolkits
... is unlikely to be supported.
... should we take this problem on?
frans: let's say there is a
single spatial ontology with a geometry datatype:
... then this will not be a problem anymore.
BartvanLeeuwen: but still the problem of tool support
frans: a common datatype like WKT would help
aharth: what they did was extend
geosparql ontology with their own property.
... they didn't want to use WKT but their own format they had
already.
... this is a repeating thing, everyone wants to use their own
format and keep doing that.
frans: that's a problem we need to solve because otherwise we don't have interoperability.
aharth: but that will not fly with these guys.
<Zakim> AndreaPerego, you wanted to mention Simon's comment on geometry encoding in GeoJSON
frans: we should compare different solutions
AndreaPerego: simon Cox had a good comment on the mailing list about in GeoJSOn using JSON arrays for this is sensible.
BartvanLeeuwen: but the problem with the array is if you serialise this back it is screwed up
LarsG: if we standardise one format would this prevent others from doing their own thing anyway?
frans: in the relational DB world it worked
eparsons: is it really an
interoperability issue on the level we're talking about?
... aren't we more concerned about interoperability on the
Thing level instead of the encoding?
BartvanLeeuwen: i suggested to Berni et al to separate the geo part and LD part on the web, but they want the whole package
LarsG: so Bart is saying use
content negotiation and choose an encoding depending on which
format is requested.
... but this asks more of the publisher
frans: geometry should be considered a data type that should be used the same in any format
LarsG: is anyone in close contact with geojson community?
eparsons: nobody really
... they are busy at IETF
phila: we had contact with them
before Sapporo
... we could ask eg if they are ok with WKT
LarsG: that would solve our problem what to write in the BP
billroberts: they would probably not want that
frans: we need to look at the
pros and cons of having coords in one string or in an
array
... the advantage of one datatype is you don't need any
conversion
aharth: they want to use
javascript to draw coordinates on a map
... wkt will be more difficult for them to parse
frans: it would need only a small library.
billroberts: they want to use it natively, not using a library
jtandy: in rdf it is not useful
to separate geometry into triples. Literal is good
... having coordinates in literal is a recommendation. Not
saying it should be wkt especially.
... seems like there is a common ground: treat it as a literal
object, not as a nested array
frans: a datatype is more durable, json might go away and be replaced
billroberts: having big rdf
literals is a pain in practice.
... having a triple refering to a separate web resource would
be good
... maybe geosparql extension needed to still be able to do
spatial things with the geometries
<Zakim> phila, you wanted to ask about NeoGeo treatment of literals
billroberts: but the serialization doesn't matter that much
phila: neogeo doesn't put the geometry into one literal, what's your experience?
aharth: a good way of doing
it.
... if it's not one big file, but links to geometries outside,
this makes file sharing more difficult.
eparsons: break for lunch
... back at 13:00 CET, 1 hour from now.
<phila> ==LUNCH==
<phila_> scribe: phila
<phila_> eparsons: Recommences the meeting
<phila_> ... We need to talk about coverages etc. this afternoon
<phila_> eparsons: It's the thing we've done least development on, but I think we're ready to make a start.
<phila_> billrobe_: I asked for it to be on the agenda to discuss what we're going to do and how.
<phila_> ... I agreed to be one of the editors
<phila_> billrobe_: My background is in the LD work, but less so in coverages - I'm going to need help from the WG
<phila_> jon: What is the scope?
<phila_> billrobe_: Quotes the charter
<phila_> ... mentions Data Cube, WaterML
<phila_> ... subsetting
<phila_> ChrisLittle: WaterMl recognises that the coverage is in time, not space
<phila_> billrobe_: So what worries me is, to what extent will that ISO standard constrain things
<Zakim> AndreaPerego, you wanted to say that RDF rep may be useful for some specific cases (e.g., centroids, bboxes)
<phila_> jtandy: When I wrote that paragraph in the charter, compliant with 19123, it was so you could figure out how your data maps to 19123, not conformant to it.
<phila_> ... We know about domains and ranges... the intention was never a formal line by line compliance.
<phila_> jtandy: This could be a Rec track doc. It says in the charter we're going to do this. We could decide that a mapping to 19123 could be the weay to do it.
<Zakim> kerry, you wanted to ask if sound can be improved?
<phila_> kerry: I can't follow what's going on...
<phila_> ... It was better this morning
billrobe_: So the other thing I'd welcome explanation on, what does it mean that it will be a formal Recommendation?
jtandy: Rec Track
billrobe_: Does that say anything about the style or content of the doc?
jtandy: It has an implication on
the process you need to work through.
... Particularly you need to be able to refer to 2 independent
implementations of all its features.
frans: In the UCR, a note was added to the description of the coverages deliverable, about new work in OGC being relevant.
jtandy: So that refers to Peter
Baumann's 'CIS' which has been approved as a work item in the
ISO process, which is hte beginning of the road, not the
end.
... An implementation schema is more detailed than a conceptual
schema.
... CIS will eventually be 19123 Part 2
billrobe_: So if there is existing work on this it makes sense to reuse.
jonblower: So if a Rec has to be implementable, what if wanted to weaken that and say intelligent things about related things. Do we have to come up with an implementable thing?
jtandy: We have the ability to
publish more or less what we like as a Note.
... The BP doc is a Note. SSN Vocab will be a Rec.
... As will Time
... How you prove that you have 2 implementations of a vocab is
that the terms are used more than once.
... If we get to the point where we don't want to make a Rec
then we can decide as a group to do that.
jonblower: I think doing
something implementable could open a can of worms and involve a
lot of people.
... I'm happy to put forward what we've done in MELODIES, but
it's early days and not BP at this stage.
... I might be comfortable talking about the issues, like when
would you use Data Cube? When would you use JSON, when is OGC's
CIS right etc.
kerry: I don't understand why we
wouldn't do a Rec Track. I see this as an ontology for
combining EO data with he data Cube
... I can find some old work that pre-dates the data Cube
... Implementation evidence is just that all terms have been
used
... All being well, I'll have a student project soon with 6-7
students implementing what we're talking about here. For them
to benefit most, implementing it in the Australian GeoScience
model would be good.
... I'd be interested in that, provided others are too.
billrobe_: The other thing that I
wanted to raise ... who do we think it's for? We have our
overall remit, but within that, it's about levels of
sophistication.
... Is it aimed at people who do this all day every day?
Non-specialists?
eparsons: I think that's fundamental and will guide us in our scope.
<kerry> if we are not aiming at the "nonspecialists' we have nothing to do
jtandy: When I wrote the bit in
the charter was - there are already infrastructures for
handling big binary files, we're not going to help them
... And there's the LD community.
... What we need to do is to be able to use some array-based
data and apply it to areas.
... My intention was app developers who want to use LOD and
coverage data in a single application. That's what I was aiming
for.
... It's hard to do at the moment.
<kerry> +1
eparsons: Are people interested in both?
jtandy: The MELODIES project recognises 8 application areas where they're linking EO data with LOD. So 8 different areas where we can say that the problem exists.
jonblower: Yep.
<eparsons> Steps out for 30 minutes
frans: Coverage is a concept from
the OGC. It's a broad concept, time series, point
clouds...
... Is it useful to apply that on the Web?
... I can image that there are several ways of modelling a time
series that don't need to bother with a coverage.
... Do we want to say to the Web that it shoujld accept the
concept of a Coverage?
<kerry> chair: kerry
jonblower: As well as following
on from Jeremy - I think Frans makes a good point.
... There's a use case extraction job here. There's addressing,
accessing, annotating coverages
... That might point us to a range of solutions.
... We might want to think about a specialisation of
that.
... What sort of thing do people actually want to do.
<Zakim> kerry, you wanted to answer frans question
phila: Highlights the CEO-LD project and its aims
kerry: I was looking at the use
cases. I got the response that people want the EO data to be
more visible and more interlinked.
... The same techniques should be available to everyone.
... Making the data available to Web develeopers is a good
thing. As is making liefe easier for specialists.
... We had that conversation about how complicated coverages
data is in Barcelona. I'm not sure that we made a decision in
that meeting.
... For me it's clear that we should talk about data that is
mappable to Data Cube.
... We talked this morning about using Data Cube with SSN. is
the data Cube too much for time series data?
... Does it work for EO? Yes.
... So I would reduce it just to data Cube.
jonblower: To relate this to the
work with the CEO-LD group - is focussing on satellite imagery.
The coverage world is wider than that.
... Time series, numerical models, etc.
billrobe_: Next question - the
schedule. I see we're due an FPWD by last September so we're
starting 5.5 months behind schedule
... with a target end dat of end of 2016
<kerry> +1 to frans comment
frans: I wanted to say something
about the previous subject. I get the impression that a lot of
the UCs are about EO data. OGC covers more. Maybe we start
wieth the EO data?
... That might help reduce the complexity?
... I can also think of use cases that are not in the OGC
definition. The microscopy slides UC for example. That gives
you raster data that may not fit the OGC defn.
... So we *could* just think about the raster data, and that
might be what people ar elooking for? Somrthing to
consider.
<Zakim> jtandy, you wanted to make a comment that datacube was illustrative
jtandy: Whilst it's attractive to
focus on raster data in the EO community, it woujld miss out
time series, numberical models etc.
... Maybe in our work we can set a boundary of the topologies
to look at.
... Data Cube was mentioned as an illustrative way of saying
how a coverage could be encoded. There's some commonality, not
that we need to end up with a recommendation that says we must
use Data Cube.
<Zakim> billrobe_, you wanted to talk about data cube
<frans> Does the data cube vocabulary suffice for time series?
jonblower: On Kerry's point. I think it woujld be good to have a look at Data Cube and see how it applies. But I don't think we should restrict ourselves to one model A coverages model includes all use cases. All coverages havea the same kind of properites and attributes, so I don't see how we would do something that only applied to EO data.
<jtandy> +1 from me ... not restrict ourselves to RDF DataCube model
jonblower: Great of Kerry has students to look at it
ChrisLittle: The microscopic
slides are a coverage and they are covered by the 19123
model.
... The Data Cube issue - you might get 2 data cubes you might
have one with geospatial coordinates defined as dimensions and
on where they're not.
<billrobe_> I agree with what Jon and others have said on data cube
kerry: Understandint that
coverage is much broader in an OGC sense... but we have the
Data Cube available to most of us, and it can handle time
series
... My suggestion is to limit oursleves to coverages that can
sensibly be encoded in the Data Cube.
jtandy: Which data cube do you mean?
kerry: the RDF Data Cube (not the geosci Aus one)
<rachel> s/Understandint aht/Understanding that/
<jtandy> [I included the 'timeseries' coverage in the charter statement specifically so we didn't focus only on EO satellite / raster data]
jonblower: Kerry, you added a
word in your last sentence that changed my view:
'sensibly.'
... So you mean relatively low volume ones, cf. 10^3 x 10^3
pixel images
kerry: It was more the mapping of the data model, where it fits the cube model that i was after.
jonblower: So you're talking about coverages with orthogonal axes, rather than triangular reference systems.
<ChrisLittle> +1 to john's comment
jonblower: Right, OK, now I understand.
billrobe_: I like Data Cube - I
do a lot of it for statistics, but I think it would be very
restrictive to only look at things that only worked in data
Cube.
... The good thing is its flexibility, the bad thing is its
verbosity.
<frans> I agree with Bill.
<jtandy> +1 to billrobe_ ... look at datacube from evaluative perspective
billrobe_: I wouldn't want to exclude otehr things at this stage.
<Zakim> jtandy, you wanted to note that the datacube might still work for describing the coverage metadata
<jonblower> I also agree with Bill
jtandy: Even if you have 10^6
points, the Data Cube might have been a useful way to describe
the coverage.
... My thought was that it might be good for the metadata,
maybe not the payload.
... I agree with Bill that we should start with the
solution.
ChrisLittle: Can I come back on the comment about ruling out point clouds. They are amenable to being represented in a data Cube... I'd vote to have point clouds in.
<jtandy> we should draw the line of coverages to exclude those with triangular mesh networks ... and point clouds - such as lidar for example
jonblower: My response to Chris would be that in that case you could represent anything in an RDF Data Cube. Whether it would be useful, smart or efficient, is another question
<Zakim> phila, you wanted to make a suggestion about elephant eating
<kerry> +1
phila: Can we start simple nad see how we go?
<kerry> +1 to billrobe_
billrobe_: It would perhaps be a good idea to look at the use cases we've got and see where that leads us. I know we don't want to add more but we haven't reviewed the UCs yet with this in mind.
<jtandy> [jtandy also noted that rectilinear grids (whose axes are not necessarily orthogonal / 90degrees) should be _in_ scope ... jonblower agreed]
<frans> I like Phil's and Bill's suggestions
<scribe> ACTION: bill to review the use cases from a Coverages point of view [recorded in http://www.w3.org/2016/02/09-sdw-minutes.html#action06]
<trackbot> Created ACTION-144 - Review the use cases from a coverages point of view [on Bill Roberts - due 2016-02-16].
rachel: One of the use cases I submitted requires point cloud data anda LIDAR so I'd like those to be attempted.
ChrisLittle: It's nice to have an ally in the Env SCiences
jtandy: But we only have a finite resource. Maybe we should identify the order in which we'll tackle things.
<rachel> +1 to Kerry's students working on this
kerry: If I get the student
support, we might have a significant extra capacity.
... But that leads on to the timing question that Bill was
talking about.
billrobe_: Coming back to what
we're obliged to do, and the time scale. I don't know whether
that's possible
... So we have to work through these steps and have some idea
of ther work involved. ANd then meet up with the schedule.
<Zakim> billrobe_, you wanted to talk about schedule
jtandy: If I can talk to the
schedule. All W3C WGs have a time line associated with them. If
you want an extension, you need to demonstrate that you are
making progress and that there is an end in sight.
... So if we can demonstrate community support and progress, we
can asl for an extension.
<kerry> +1
phila: Talked a bit abouit asking for an extension when you have a realistic new timeline, not waiting until the lsat minute.
jtandy: So by May we should have an idea of when we want to finish?
kerry: Would anyone like to say
that extending wouldn't be possible from their POV?
... Any more comments about coverages at this point?
jonblower: There is some stuff
that we've been doing in the MELODIES that I can show.
... If that would be useful.
<rachel> fine by me
ChrisLittle: I just wanted to say, I don't see any mileage in talking more about time.
==Short Pause for tea making==
<rachel> [use case for point cloud, irregular mesh coverages: http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DisseminationOf3DGeologicalData]
<billrobe_> are you there kerry and rachel?
<kerry> https://www.w3.org/2015/spatial/wiki/SSN_Tasks#Modularisation_topic
<kerry> chair: edparsons
<rachel> I'm back !
<aharth> scribe: aharth
<eparsons> thanks aharth
jonblower: presents current state
of the melodies project
... coverage is any kind of mapping between points in
space/time to data values
... satellite images, temperatures in space/time, point
clouds...
... different kinds of coverages are distinguished by coverages
in space and time
... basically a grid of data in space and time
<frans> Why is point geometry not a coverage?
jonblower: land cover product on
screen is a kind of coverage
... three data objects make up a coverage
... the domain is the set of points for which we have data
values
... the domain varies between coverages
... the range is just the list of data values
... in many encodings there are rules for mapping points in the
domain to items in the list of the range
... the range can just be a list of numbers
... terminology taken from mathematical functions
... then there's the range metadata
... how to interpret the values in the range
... in applications domain, range and metadata are separate
bits of information that might be used separately
... the ogc coverage implementation schema consists basically
of domain, range and range metadata
... rdf is not good at representing the range values
... but rdf could be useful to describe range metadata,
possibly domain
... issue is to encode range values, one possible solution from
the melodies project is shown
... how do you get data from server to web browser that the
data can be manipulated and processed within the web
browser/client
... CoverageJSON format specification
...
https://github.com/Reading-eScience-Centre/coveragejson/blob/master/spec.md
(?)
... we defined specifications for the types of coverages we are
interested in (e.g., grids)
... data values can be represented in-line or as a separate
document
phila: domain is quite terse,
range values can be big
... why is domain small, and range rather large?
jonblower: domain can be represented more compactly, you do not need to list the full cartesian product
<Zakim> LarsG, you wanted to ask if Jon's explanation of coverage is available somewhere
jonblower: plus there can be
several ranges (for example, measure temperature and other
things)
... some satellite product have up to 200 different ranges
LarsG: thank you for the
explanation what coverage is about
... is that written up somewhere?
... we could refer that from our documents for people who are
not versed in geographical sciences
<rachel> [thanks Jon, very clear explanation]
<eparsons> http://external.opengeospatial.org/twiki_public/CoveragesDWG/WebHome
frans: the idea that coverage consists of three different bins is very helpful
jonblower: that works for every discrete coverage
<kerry> also see https://www.w3.org/2015/spatial/wiki/Cov_References
jonblower: for analytical coverages (based on mathematical functions that are continuous/infinite) that might not work well
eparsons: then you'd need to specify a sampling frame?
jonblower: yes
billrobe_: supposed i have data for manchester, do i need to read the whole domain?
jonblower: we'll come to
that
... for the "metadata" bits, coordinate systems, parameters on
range metadata..., that basically is RDF in disguise (via
JSON-LD)
... explains JSON-LD @context header/document
... the example includes data like profiles, calendar
systems...
... for the range, you might want to have something more
efficient than JSON
... then again, compression works well on JSON text
... gzipped json is efficient compared to binary formats
... range values can be served in different ways, that's where
the api comes in
... haven't considered the standardisation discussion yet,
wanted to have something first that works for us
ChrisLittle: what is "Gregorian"? with our without leap seconds?
jonblower: we reference an
external definition, defined there
... the coverage community ignores small coverages
... some coverages might be fairly small, but you have lots of
them
... coverage collections is something we have to think
about
... CoverageJSON is a format to describe single coverages
... but you might have 10k, and you only want to select
1k
... we looked into designing a REST API, but that's quite
experimental
... we want to bring coverages to people who do not want to
deal with a complex service
... we support content negotiation, that you can use curl/wget
to access data
... we use HTTP headers to control what the client requests and
the server returns
... paging, for example, is handled via HTTP headers
... idea is to break datasets into smaller bits, provide an api
to allow people to inquire about smaller bits
frans: why did you use pages, not tiles?
jonblower: a server that does not
have spatial subsetting capability (e.g., a web server) you
need something simple
... if the server supports spatial subsetting, you can do that,
basically use the opensearch capabilites for bounding box
queries
<Zakim> jtandy, you wanted to ask is spatial / temporal filter is on collections or cover
<billrobe_> https://github.com/Reading-eScience-Centre/coveragejson
jtandy: how do represent spatial
and temporal filters?
... how to access sample points?
jonblower: there is a way to access the point of the domain based on an index
frans: how to apply the slicing/subsetting functionality in QB
ChrisLittle: we've done some initial work on tiling in ogc
<Zakim> jtandy, you wanted to talk about datacube slices and subsets
jtandy: inside QB, they talk
about subsets and slices, but it's pretty arbitrary how to set
that up
... shouldn't get hung up on QB slices
frans: interesting to have a more general api
jtandy: in QB you specify how to slice your data when you publish it, with the CoverageJSON api you can do query-time slicing
ChrisLittle: here's a trade-off between scalability and flexiblity
jonblower: shows examples of
hydra descriptions for the api
... there are other things as part of a stack on top of the
coverage foundations
... on the github page https://github.com/Reading-eScience-Centre/coveragejson/
... initial work on api spec, javascript libraries, plugin for
leaflet are available
... we use the technologies in a demo portal within a web
browser (HTML5..., subsetting on the server side via api)
... we also provide GeoDCAT AP descriptions
... because we have the data in a browser we can apply mappings
and process the data locally in the browser (e.g., remap
melodies land cover to modis scheme)
eparsons: quite quick, how big is the data?
jonblower: around 4k data points
in the north, 2k data points in east/weast
... loads as tiles, preloaded before the demo, zooming triggers
reloading of higher resolution tiles
frans: so you have a pyramid of tiles?
jonblower: generated on the fly,
data fits in memory on the server, we do tiling on-demand
... we think we describe the data well enough to access
multiple different coverages and integrate those (e.g., using
inference in OWL)
jtandy: just to confirm, the data is in json arrays which is sucked into a browser
jonblower: before we had a
mapping service to get tiles from the server with many
roundtrips
... running in the browser is possible though with increased
bandwidth and better browser performance
... the api could also work based on static files if you would
like to do that
<Zakim> phila, you wanted to ask about how we can help
jonblower: not necessariliy
needed to implement a server
... javascript used to plot data as a zoomable widget
phila: sounds as if there's a lot
of stuff there
... you showed two documents: coverageJSON, which is
JSON-LD
jonblower: not fully JSON-LD because of the range values
phila: we could take that
approach as basis for standardisation?
... turn the vocabulary which has linked data where it makes
sense and does not use linked data where it does not make
sense
... one hesitation is that subsetting work is a big one, but
not sure how well the existing method would work
... but there's almost a working draft there
... http link headers are useful
eparsons: there are some
challenges in socialising that back to the ogc community
... there are well-established views on how to handle
coverages
jonblower: there are discussions
around getting a json view on coverages
... but still ongoing work, concepts of json serialisation
might deviate from the concepts of the xml serialisation
ChrisLittle: good way to go
forward as far as i have seen here
... there's active work in ogc on coverages
... the QB misses some geo things
... for example, slicing/dicing the cube is missing
eparsons: do you see a division
between qb and coverage
... the people involved are different, concepts might be
similar
ChrisLittle: there are
similarities, for example city 3d work
... mechanisms are similar
... and fits into a bigger map
<kerry> see https://www.w3.org/2011/gld/track/issues/34 for the qb:subslice that was dropped from the datacube
billrobe_: i like what jon
presented, it works, simple, principled, powerful in practice,
web-y
... what i don't know are the alternatives
... we need to enumerate the alternatives
jtandy: don't know if there are
many alternatives
... goes into similar direction to what peter baumann did with
the xml stuff
... but targeted for web developers
... direction is right, details might need discussion
... one thing you might want to do is processing in the
browser
jonblower: we do some client-side processing
frans: two questions
... metadata is DCAT, does the metadata identify format and api
or are they separate?
... in DCAT you have a distribution, and the distribution has a
format
... file-centric view based on documents
AndreaPerego: for example, you cannot say that something is a sparql endpoint, you need void for that
jonblower: we used to use mime types
frans: one problem with coverage
is that you have large blobs of data
... but the subsetting would take care of that?
eparsons: you could use whatever
technology you want on the server side
... all what jon describes is the mechanisms for
interaction
frans: you need to limit the amounts of data that the api serves
eparsons: wfs does not have a mechanism like that
jonblower: at least need
mechanism to tell the client: "the result is too big"
... do a http get on a large coverage collection
... and you would get a redirect to the first result page
... and links to next/prev
frans: how about not getting any
data at all, but only the metadata
... that you can pose smaller queries
jonblower: we use hydra to
partially describe the api
... difficult to describe the api in a general way that a
general client can understand
... curl does at least http redirects
billrobe_: sounds like a good way
to start
... we should see how to reconcile w3c/ogc views
jtandy: we should read the material before we go to china
<scribe> ACTION: jonblower to chase mike to update the JSONCoverage document [recorded in http://www.w3.org/2016/02/09-sdw-minutes.html#action07]
<trackbot> Created ACTION-145 - Chase mike to update the jsoncoverage document [on Jon Blower - due 2016-02-16].
<eparsons> action billrobe_ to update on coverage plans following China Trip
<trackbot> Error finding 'billrobe_'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
jonblower: there is the
interleaved format (which is domain:range pairs, rather like a
csv file)
... especially for streaming and smaller formats
... but we do not have that in CoverageJSON
<rachel> [should that be chase maik (Reichert) instead of chase Maik ?]
eparsons: i worry about our
bandwidth, there are many activities going on
... are the telecons we have are enough now that we have many
things going on in parallel
<kerry> not an unnecessary panic!
eparsons: the subtopics are more of interest to particular groups
<kerry> +q
eparsons: one possibility would be to have separate telecons for different groups, with the "main" telco to sync up
kerry: we might have to do that,
issue could be that people only go to the meeting of the
particular subtopic
... time/coverage/ssn and best practice could be split
ChrisLittle: maybe split off
time, maybe have a large meeting every fortnight
... specialised ones maybe in parallel
<Zakim> phila, you wanted to talk about task forces and weekly rotations
ChrisLittle: we could then better fit the meeting times
<kerry> +q
phila: what the DWBP does is to
rotate through the deliverables each week
... there are three deliverables
... short bit for each of the three, and then the focus is on
one of the three topics
jtandy: so once a fortnight a plenary, other weeks the subtopics in parallel
kerry: i understand the proposal, is parallel at the same time?
eparsons: not necessarily, depending on what the groups wish
kerry: rational proposal to start from, rotating through different deliverables one a week might be too slow
eparsons: we will make a proposal to the group for the modus operandi moving forward
<jtandy> [subtopics: BP, Coverage, Time, SSN ... the use case issues will be rolled into the subtopics; don't need a separate call for UCR]
kerry: we may not have enough chairs to manage all the meetings
phila: need to involve the editors for organising meetings
eparsons: any other comments/issues?
jtandy: given we have four
subtopics, some people might be interested in more than one,
i'm interested in coverage and bp
... de-conflict meeting times as much as possible
ChrisLittle: agenda page then could have the list of different meetings
eparsons: we would like to have
some regularity in the meeting times so that other people can
drop in
... we are about done, thanks for the hosts, linda for
organising
RESOLUTION: Thank you Geonovum
<scribe> ... done, meeting adjourned
<ChrisLittle> and thank you Linda for the chocolate
<rachel> claps Linda for hosting, Kerry for staying up late, bye!
<ChrisLittle> bye