Spatial Data on the Web IG - TPAC F2F - Day 2/2
23 October 2018
[see yesterday's minutes for most people. Clemens, Michael Jacoby, Simon, and Maxime introduce themselves to the group]
Jeremy recaps yesterday's discussions.
Discussions on WebVMT, MapML, CityJSON, Statistical Data on the Web, link with moving objects and ARML with Immersive Web folks who were in the room.
Simon: No significant updates since last time we talked.
… [showing the extensions document]
… These are the two extensions. I decided to put them in a separate document, with the intention that it be published as a Note by the Interest Group.
… Two features: the feature of interest of an observation, active sampling... is always a proximate feature of interest. However, for many use cases, as far as the users are concerned, the thing of interest may not be that immediate feature of interest, which may be a sample of a sample of a feature of interest.
… [example of rock properties and aquifer]
… First feature is to add a relation to link to the ultimate feature of interest.
… [scribe interrupted by himself, missed a few sentences]
… A set of observations would always be made as a collection. The second feature provides the equivalent in the SSN style.
… Describe all the observations of a slice in the data cube. This allows us to have an alternative view.
… The extensions are simply the definition of one new class and two properties.
… Class is ObservationCollection, properties are hasMember and hasUltimateFeatureOfInterest.
… Given a sampling chain, you can derive the ultimate feature of interest using rules described in the doc in SPARQL.
… I only considered collection of observations because of the data cube case.
… I'm working with Eric Prudhommeaux to rewrite rules in ShEx.
Maxime: Three questions. On the ultimate feature of interest, would it make sense to switch [bad quality audio]?
Simon: I think it does not make sense. You can navigate by following the sample chain.
Maxime: Regarding ObservationCollection, would it make sense to define it as well for Actuation?
Simon: I think it would make sense, yes.
… I'm less familiar with actuation use cases. I'm much more familiar with observation use cases.
Maxime: OK. In 4.1.1, some proof reading may be needed.
… Question around ShEx
Simon: I must say I'm not familiar with ShEx. More with SHACL. I didn't get the SPARQL construct to work.
Maxime: The rule on hasUltimateFeatureOfInterest seems very complicated, can you explain it?
Simon: [going through the rule]
… There are some test cases in the GitHub repository. It might be implemented more efficiently. This appeared to get the proper results according to the test cases I prepared.
ChrisLittle: A trivial point. I noticed "transitively" spelled wrongly.
<jtandy> https://github.com/w3c/sdw/projects/7
SimonCox: I will fix that.
jtandy: If we look at the project page, it says that you're working on validating SPARQL queries in 4.3, is that now complete?
SimonCox: Still waiting for feedback from Eric.
jtandy: The second one is on understanding the relationship between ObservationCollection and RDF Data Cube.
SimonCox: Still need to write something down. I've learnt a lot about RDF Data Cube in the recent months with experts. That has convinced me that this extension is the right thing to do, but I still need to formulate that in the doc.
billroberts: In the discussion we had yesterday, we said that the scope of the Statistical Data on the Web Best Practices should be government statistics and scientific statistics, so the work you're describing here about aligning with the RDF Data Cube seems very useful.
<SimonCox> see DXWG strawman here https://github.com/w3c/dxwg/wiki/Data-aspects-semantics
SimonCox: The DDI people have something called DISCO
… Halfway down the page I pasted, there is a proposed research data profile of DCAT.
… A research dataset would have a rectangular dataset, which could be an RDF Data Cube. The idea being that we're looking at an homogeneous collection of data.
… The current proposal has schema.org terms.
jtandy: The last piece that you have on the project page is adding examples in section 5. That's still work to do?
SimonCox: Yes. If anyone wants to join...
jtandy: You're still the only person who's editing the document.
SimonCox: That's right. If you look at the repository, there is an example folded in there.
<mlefranc> I'll comment the table of contents of https://www.w3.org/TR/vocab-data-cube/
mlefranc: Regarding alignment with Data Cube, just glanced over it, I don't think that's quite comparable.
… [audio still bad]
… The ObservationCollection is a very simple case of data cubes and I don't think that we need to go to the full depth of data cubes.
SimonCox: Right. ObservationCollection is much more flexible. These things are clearly related. I agree that it does not make sense to do systemic axomization.
… I'll point out what you cannot do with a Data Cube and that you can do with this.
ChrisLittle: Trying to understand what a rectangular dataset is, is it a non-sparse dataset?
SimonCox: Yes.
ChrisLittle: I'm trying to write a white paper about portrayal in the OGC. Connecting to the data cube sort of works provided observations can be features.
jtandy: An observation is a feature, right?
SimonCox: Yes.
jtandy: In that sense, that's a permissive statement for doing what you want.
SimonCox: There's increased interest in this work both within the SDW IG and in Australia.
jtandy: Your intention is to publish this as a Note. What do you need before we're ready to publish as a Note?
SimonCox: I need to tidy the document. The cross-review that happened today has been useful, more would be good.
… What would be the decision process for the IG to publish this as a W3C Note?
jtandy: This group can agree to publish notes without problem. It's just up to us to agree that it's ready to go.
… When we were in WG phase, we had a vote. It would be useful to have a proposal in front of the group. From my perspective, it would be good to have a timeline and to be able to point to evidence of implementation.
<SimonCox> +1 to FPWD !
tidoust: publish as a working draft first would be good
… to invite external feedback
SimonCox: makes total sense
tidoust: we can decide to publish a FPWD today
jtandy: Right, if you're content, Simon, I would propose to do the vote now.
SimonCox: Right, I just need to make some editorial fixes.
jtandy: OK, with this caveat, I would propose that we publish this document as FPWD.
PROPOSAL: Publish the SSN Extensions draft as First Public Working Draft (once editorial fixes are in)
<ChrisLittle> +1 to FPWD after editorial fixes
<jtandy> +1
<tidoust> +1
<brinkwoman> +1
<mlefranc> +1 to FPWD, congrats Simon
<billroberts> +1
<Chrisjarvis> +1
<SimonCox> +1
<MichaelGordon> +1
Resolved: Publish the SSN Extensions draft as First Public Working Draft (once editorial fixes are in)
jtandy: I'll let you work with Francois to get the document published as FPWD. From then we'll get external review and then publish as final Note.
jtandy: Two oustanding issues #1006 and #1022
… What I'd like to do is to come to a resolution on these issues.
Move hasProperty from SSN to SOSA namespace (#1006)
SimonCox: Regarding #1006, the proposal was that one of the properties in the SSN namespace would arguably have been better in the core namespace. My sense is that making that change at this stage would be difficult procedurally.
… It would involve making a normative change to the spec. I'm not sure that's in scope of the Interest Group.
jtandy: So your view is that it's normative, the change will break existing implementations.
<mlefranc> not sameAs, but equivalentProperty
SimonCox: Yes. However, it would make sense to add an hasProperty property to the SOSA namesapce and then add a sameAs property (well equivalentProperty according to Maxime's comment)
[recognition that it was a mistake in the WG]
SimonCox: Adding a property would work, but it's not an erratum. It's a new feature.
jtandy: My feeling is that you shouldn't remove it from the SSN namespace.
<mlefranc> not a mistake to me (we voted), but we could not make up our minds sufficiently on time
jtandy: If we can treat this as an erratum, that would be great.
<brinkwoman> tidoust: from a process perspective its a new feature, not an erratum
<brinkwoman> ... in this case we could argue it was a mistake but then the group would have to agree it's a mistake
<brinkwoman> ... I need to get a green light internally to bend the process a little bit
<SimonCox> 1. add sosa:hasProperty in sosa.ttl
<mlefranc> please add also axiom ssn:hasProperty owl:propertyChainAxiom ( [ owl:inverseOf sosa:hasFeatureOfInterest ] sosa:observedProperty ) .
<SimonCox> 2. add ssn:hasProperty owl:equivalentProperty sosa:hasProperty . to ssn.ttl
<mlefranc> (see end of issue 1006)
PROPOSAL: Add an hasProperty property to the SOSA namespace, with an equivalentProperty axiom as an errata change
<mlefranc> yes to SimonCox #2 too
<SimonCox> 3. ssn:hasProperty owl:propertyChainAxiom ( [ owl:inverseOf sosa:hasFeatureOfInterest ] sosa:observedProperty ) . to ssn.ttl
[discussion about axiomatization and notably #3 in the list above]
jtandy: So, from your perspective, these 3 points make sense to you
PROPOSAL: After checking with other SSN editors, add an hasProperty property to the SOSA namespace, with an "ssn:hasProperty owl:equivalentProperty sosa:hasProperty" axiom, and "ssn:hasProperty owl:propertyChainAxiom ( [ owl:inverseOf sosa:hasFeatureOfInterest ] sosa:observedProperty )" as errata change
<mlefranc> +1
<ChrisLittle> +1
<SimonCox> +1
<brinkwoman> +1
<Chrisjarvis> +1
<jtandy> +1
<ClemensPortele> +1
<Michael_Jacoby> +1
<RobSmith> +1
<MichaelGordon> +1
Resolved: After checking with other SSN editors, add an hasProperty property to the SOSA namespace, with an "ssn:hasProperty owl:equivalentProperty sosa:hasProperty" axiom, and "ssn:hasProperty owl:propertyChainAxiom ( [ owl:inverseOf sosa:hasFeatureOfInterest ] sosa:observedProperty )" as errata change
jtandy: Simon and Maxime, can you check that with other editors?
SimonCox: I'll do it.
jtandy: Then update #1006. If that comes back as a positive, can you check whether that's possible, Francois?
tidoust: Yes.
[discussion on giving other editors two weeks to answer, and consider lack of response as assent]
-> https://github.com/w3c/sdw/issues/1022
Inverse property for ssn:hasSubSystem (#1022)
mlefranc: The commenter claims that it cannot use the property as-is.
… For me, this does not make sense, the inverseProperty relation means that you can use properties as-is.
… I suggest not making any change.
… This would require creating a new property in the normative section of the SSN. I don't think that we want to do that.
… It's just syntactic sugar.
<SimonCox> Note that the proposer did not respond to Maxime's response to his proposal. Maybe lost interest?
mlefranc: It could be added to a possible v2, but not now.
SimonCox: I note the issue was raised back in March, Maxime responded within 2 days, and the commenter did not respond, so may have lost interest.
<ChrisLittle> +1
PROPOSAL: Re. #1022, we will not add an inverse property for ssn:hasSubSystem, because this would introduce a normative change, and can be done in one's own applications
<mlefranc> +1
<AndreaPerego> +1
<PeterRushforth> +1
<jtandy> +1
<brinkwoman> +1
<SimonCox> +1
<tidoust> +1
<ClemensPortele> +1
<billroberts> +1
<RobSmith> +1
<ChrisLittle> +1
<MichaelGordon> +1
<Chrisjarvis> +1
Resolved: Re. #1022, we will not add an inverse property for ssn:hasSubSystem, because this would introduce a normative change, and can be done in one's own applications
jtandy: Two outstanding issues there as well #987 and #988.
… When we exchanged over email, the feeling that we didn't want to address the issue because it would introduce breaking changes and we explicitly favoured backward compatibility.
SimonCox: Right. This was brought two months after publication.
… With the Time Ontology, we were dealing with artefacts that dated back 10 years, and some of the changes that are being proposed would break up some of these artefacts, so even if it had been brought in time, we wouldn't have been able to incorporate it as-is.
… It would be hard to remove gDay, gMonth, gYear without breaking existing implementations.
ChrisLittle: There's a kind of conflict between doing something that is good enough, and trying to go to the last detail. We know it's brittle, and I'm happy with the road we took.
PROPOSAL: Re #987 and #988, we will not make no change to the Time Ontology on the basis that the aim of the Time ontology was to ensure backward compatibility with existing implementations.
PROPOSAL: Re #987, we will not make any change to the Time Ontology on the basis that the aim of the Time ontology was to ensure backward compatibility with existing implementations.
[We marked datetime as deprecated. We did fiddle with the exact datatypes. We could perhaps do the same thing with gDay, gMonth, gYear. We could recommend people not to use these properties]
<mlefranc> +1
[There would be implications though, because we're not proposing alternatives, so marking them deprecated does not make sense]
PROPOSAL: Re #987, we will not make any change to the Time Ontology on the basis that the aim of the Time ontology was to ensure backward compatibility with existing implementations.
<SimonCox> +1
<ChrisLittle> +1
<brinkwoman> +1
<tidoust> +1
<AndreaPerego> +1
<Chrisjarvis> +1
<ClemensPortele> +1
<MichaelGordon> +1
<mlefranc> +1
<Michael_Jacoby> +1
<jtandy> +1
<PeterRushforth> +1
Resolved: Re #987, we will not make any change to the Time Ontology on the basis that the aim of the Time ontology was to ensure backward compatibility with existing implementations.
SimonCox: #988 is different. It describes a requirement for recurring time.
… If it had come up 3 years ago, I think we would have considered to include it.
… It's just a little bit out of scope of what was considered for OWL Time and therefore not treated.
… If anyone has the appetite to develop an extension to the ontology, then that could fit there.
PROPOSAL: Re. #988, it introduces a useful requirement to introduce recurring instants, but addition to the OWL Time ontology would require re-chartering the group. The Interest Group is not planning on working on this feature for now, but would welcome an extension proposal.
<jtandy> +1
<brinkwoman> +1
<Michael_Jacoby> +1
<Chrisjarvis> +1
<PeterRushforth> +1
<ChrisLittle> +1
<SimonCox> +1
<tidoust> +1
<RobSmith> +1
<AndreaPerego> +1
Resolved: Re. #988, it introduces a useful requirement to introduce recurring instants, but addition to the OWL Time ontology would require re-chartering the group. The Interest Group is not planning on working on this feature for now, but would welcome an extension proposal.
MichaelGordon: SDW BP agenda status, Inspire, Google searchc and etc
… Published a summary of BPs being used
… current focus now encouraging adoption
ClemensPortele: report on BP making data searchable, wrote report about EU Inspire initiative
… and Google dataset search released in Sept 2018
<ClemensPortele> https://webgate.ec.europa.eu/fpfis/wikis/display/InspireMIG/Google+Dataset+Search+workshop+2018-09-19
ClemensPortele: EU Data Portal, JRC also present at workshop
… discussed indexing both datasets and individual 'objects'
… JRC Inspire Implementation Group experimenting with indexing with schema.org
… more activity planned in several European countries
MichaelGordon: question sbout any potential new BPs or changes to exsting BPs?
ClemensPortele: interested in improving the search results. What works, what does not, to improve future guidance, especially at object level.
ClemensPortele: looking at the paging aspect of results in the next few months
<Zakim> AndreaPerego, you wanted to report about related work in DXWG (in case Simon didn't do that already...)
MichaelGordon: two implementation reports: Clemens, Australian and potentially a third from Netherlands
AndreaPerego: W3C DXWG work relevant. revising the Data Catalogue vocabulary to include services as first class citizens, such as OGC services, APIs, etc.
<AndreaPerego> Call for comments: http://lists.w3.org/Archives/Public/public-dxwg-comments/2018Oct/0001.html
<AndreaPerego> DCAT 2nd draft: https://www.w3.org/TR/vocab-dcat-2/
AndreaPerego: should enable better use of
… DCAT for geospatial data
… European profile of DCAT, DCAT-AP exists
… services in geospatial domain becoming more important, in US and Europe.
… and in different sectors and domains
… exposing more capabilities
… welcome review of the drafts
<AndreaPerego> DCAT schema: https://www.w3.org/TR/vocab-dcat-2/#fig1
ClemensPortele: services overlap with distributions. What is the distinction?
AndreaPerego: services in DCAT are not equivalent. Data Service to give access. Distribution links the data to the service.
ClemensPortele: preferred the older approach which is much clearer
MichaelGordon: need to review BPs wherever they are mentioned in DCAT
jtandy: proposing to observe DXWG on Friday. Will review the docs
MichaelGordon: summary: two complete implementation reports, with scorecard on GitHub
… reports summarises 'conformance' for each BP
… shold help idnetify any common approaches
… All implement most of the BPs, except #14
… BP2 indexing not granular because of millions of objects, and pagination an issue. Need to discuss with Google.
ClemensPortele: what is the business value of indexing all the invidual objects?
MichaelGordon: An existing URI does not imply need to index that item.
<Zakim> AndreaPerego, you wanted to ask if there's any idea why BP14 is not implemented.
MichaelGordon: will discuss BP 14 on next slide
RobSmith: WebVMT could be used for indexing a video, but no feed back from Google after discussion with Ed Parsons
… other use cases such as drones photoing offshore wind turbines, or YouTube. Need searching by location
ClemensPortele: most end user searches are for one individual thing. Published data not useful for this.
jtandy: this is about indexing individual things,from multiple sources. Does this link to eixsting Google work? Asked of Google staff present.
… dumb example: all post boxes in Lyon.
ClemensPortele: also buildings. People who live there are interested and involled
… thnking of adding links to government services for that area
… This is a useful set of stories, which ties in with video too, but this is not in current Google knowledge graph.
Michael from Google: Will ask about cost and size of problem
ClemensPortele: intention to do this publishing in HTML as well as other machinable formats
ClemensPortele: example of a parcel in a protected area could be demonstrated.
PeterRushforth: this is a MapML use case.
… other things on the map could increase the page ranking
MichaelGordon: the spatial thing itself is more important than the map of it.
ClemensPortele: currently it is the schema.org thing that is indexed, in a JSON prepresentation, not the map.
PeterRushforth: assumes the objectson the map have metadata
michael from Google: are there any current examples? different ways such as service side, client side or dynamic?
ClemensPortele: implementor decides. easiest was with Leaflet queries for each media type, at client side
jtandy: We are encouraging people to publish better, not just 'here is a dataset@
RobSmith: is the location alread know to the search engines?
ClemensPortele: yes
PeterRushforth: what if another item or incident nearby, perhaps on a different map, visible or linkable?
… completely unrelated except by location proximity only
MichaelGordon: if things are actually touching/within etc OK, but 'near' is problematic
MichaelGordon: such a search with a bbox would work.
ClemensPortele: How much do you have to describe your data, with locations, to be useful?
jtandy: SDWWG advocated that spatial things should publish the locations, not all possible links
tidoust: surely the connection via the map can already be made by metadata existing for the objects on the map
RobSmith: building shape is already encoded in the coordinates. the shape of the map is already known, so info already known for identifying nearness.
jtandy: This is a useful discussion, to be continued later in the afternoon.
MichaelGordon: let's now cover BP14 Positional accuracy. Not implemented by three implementation reports
… further reports may indicate whether more work needed for this BP14
AndreaPerego: Supports the use of a code list to indicate accuracy. Need also UoM indication
… A registry for the code lists would be useful.
… can we explore UoM?
MichaelGordon: what infrastructure maya be needed to support BP14?
* thank you Andrea
ClemensPortele: who specifies the code list details?
ClemensPortele: also the issue of transforming CRSs may alter accuracy/precision
jtandy: some use cases were geological and boreholes, and relative position was appropriate. Other use case may differ
MichaelGordon: e may need more explanation of the BP
AndreaPerego: Spatial resolution in metadata is a concrete use case for BP14, but is not easy. Both UoM and Code Lists would be helpful
jtandy: propose discussion continuation at 16:00 CEST (14:00 UTC)
no objections
Linda: Context is discussions we had during an OGC meeting on SensorThings, and the perceived need to liaise with the W3C work on Web of Things to make sure works were aligned.
Michael_Jacoby: [showing presentation] OGC SensorThings API. Standard for exchanging sensor data and metadata.
… Like Sensor Observation Service (SOS) but RESTful and using JSON. 3 parts in the standard: sensing, tasking (not yet released but agreed upon) and rule engine.
… It covers both a data model and an API definition. Simple, intuitive and very powerful. There exist multiple implementations already.
… Alternative standards are more complex (SOS, oneM2M because target audience is different) or only covering the data model (SSN, iot.schema.org)
… [going through data model]. Quite close to SSN in some respect.
… For the API, we have URL patterns with a RESTful API.
… [going through GET/POST/PUT/... semantics and examples]
… Most of the query options come from OData, including paging, expanding.
… You can nest expansion queries.
… Lots of API functions (logical, mathematical, string functions) for the query language
… Also geo functions.
… Main question is: how OGC SensorThings API relate to W3C WoT Thing Description and API go together?
… One thing with different locations and representations are possible in the data model.
… Currently, we're using pure JSON with JSON-LD-like properties.
Michael_McCool: JSON-LD is rechartering to work on v1.1, to make it much more JSON-like. It makes it much easier to take JSON document and annotate them with semantics.
… We recently added URL templates to thing description. Looking at your system, I can see how this can map, except for advanced query functions.
… That's one question that comes to my mind.
<McCool> https://github.com/w3c/wot/blob/master/PRESENTATIONS/wot-summary-and-roadmap-06-2018.pptx
Michael_McCool: Other than that, I think things would fit pretty well.
Michael_Jacoby: The Sensor class in our case would be described by a Thing and Properties. I tried to do the mapping and came across two problems.
… If I want to get the value of a property name, then I need to GET one particular URL. To write, I need to send a PATCH to a different URL.
Michael_McCool: That can be supported in the current spec. We're just in the process of updating it.
… We do have MQTT bindings in the work. You can observe through MQTT and read/write through HTTP. Which I think addresses what you're talking about.
… URL templates are pretty new features though.
… The WoT WG was started 2 years ago. The Thing Description is a JSON-LD spec for describin APIs of things.
… So I think it's a good test case for our work.
… Our query language for searching thing descriptions is SPARQL.
… TD uses JSON-LD 1.1 features which we hope will be published as a Recommendation before our deliverables.
… [showing example]
… We're using JSON-LD to describe the payload that you get.
… We have 3 categories of things, properties that you can observe (the idea is that you'll get state updates), actions, and events.
… For RESTful APIs we have observed-type eventing.
… If you want guaranteed delivery, it may make sense to use events.
Michael_Koster: So you can change properties through actions and be notified of updates through events.
Michael_McCool: There can be multiple forms to describe RESTful APIs.
… You can use that to describe some particularities of your API.
ChrisLittle: For security, have you looked at the OGC security for services that got published this year?
Michael_McCool: Not for now.
ChrisLittle: It supports different OAuth security schemes
Michael_McCool: We're keeping an eye on a number of other organizations, e.g. IETF.
… We're only trying to describe existing protocols in the Thing Description.
… You can add new ones as extensions.
jtandy: Coming back to a previous point, the WoT Thing Description should be able to describe a SensorThing.
Michael_McCool: Right, and that's a good test case for the Thing Description.
… We're looking at OCF, Mozilla things, etc. for test cases. This is a good additional target.
<brinkwoman> tidoust: trying to understand... where would the query language fit in the thing description
<McCool> https://w3c.github.io/wot-thing-description/
Michael_McCool: There's another project that is not yet Rec track that is thing discovery, where this would fit.
… TD is more about describing services and things, and sensors.
… URL templates are where you can express variables as part of your requests.
<kaz> [to be clear, so far WoT has Scripting API to expose the capability of Things; regarding discovery, there has been discussion and demo on Thing Directory but that is not yet included in the REC track ]
Michael_Koster: this may be more aligned with bulk interaction that we're discussing for the Thing Description.
Michael_McCool: We're still incubating the thing directory, e.g. bulk discovery.
Michael_Koster: Normal use case is one SensorThing service that gives a collection of things
Michael_Jacoby: Yes, that's the main use case. It's a directory of devices.
Michael_McCool: So you're combining things from Thing Description and Thing Directory.
… We probably should be standardizing Thing Directory, although not in our charter for now.
jtandy: Given that SensorThing provides an interesting test case, I'm seeing a useful implementation example for your CR case.
… I'm wondering how to physically create a piece of work to try to bring these things together.
Michael_McCool: We do various test cases in our plugfest.
… We also do online plugfests.
… The online one would be easy for you to join.
… And we can test whether things work. The issue being how much coverage you'd like to test.
jtandy: Is that something that you'd be able to support?
Michael_Jacoby: Yes, we can definitely setup a server.
Michael_McCool: We could also auto-generate data from introspection data if that's possible.
Michael_Koster: So different work activities here. Generating TD out of SensorThing. Then Thing Discovery. Semantic interoperability of functions.
Michael_McCool: Right, we need to agree on the coverage, but it would strengthen our CR work for sure.
… The online plugfest is in December.
… The physical plugfest has not been decided yet.
kaz: We usually run plugfests along with F2F, current plan is holding the next one in Tokyo.
jtandy: From a SDW IG perspective, we'd be interested to know how this unfolds.
Michael_McCool: We certainly want to document the experience.
<kaz> [btw, please note that WoT WG has 2 pieces separately: 1. spec generation mainly for Thing Description and 2. PoC named "PlugFest". today's discussion is very useful for PlugFest but not directly for the TD spec generation (we need to generate tests for CR/PR) though potential feedback to TD would be welcome ]
Michael_McCool: Workshop likely to be organized next year, probably around June.
Michael_Jacoby: I'm positively surprised that most of the things that I thought were not part of WoT are actually part of WoT now.
… The Thing Directory is something I had not heard about before.
<McCool> https://www.w3.org/TR/wot-thing-description/
Michael_Jacoby: I think it's very helpful
… If mapping works, SensorThings could be integrated in bigger networks.
… SensorThing is used in different use cases, and in each case extends the core vocabulary of SensorThing. The discussion is ongoing in SensorThing.
Michael_McCool: We haven't thought about adding location and context per se. [Link to Linked Building Data CG meeting earlier this week]
… We can certainly make prototypes.
Anicic: So far we don't have many features of interest, so no real link from iot.schema.org. You can use other ontologies though. Common practice in plugfests.
ChrisLittle: Practicality of plugfests. [mentions next OGC meetings for possible synchronization]
brinkwoman: Thanks everyone for coming. Pretty useful discussion
https://w3c.github.io/web-roadmaps/sdw/
https://github.com/w3c/sdw/issues/1065
brinkwoman: I have worked on the roadmap over summer and am looking for feedback
brinkwoman: It could be viewed as an overview of the standardisation landscape
brinkwoman: Or it could be viewed as a list of topics the WG works on.
brinkwoman: Or it can highlight specs that should not be used.
brinkwoman: Right now still struggling a bit with the grouping into 4 topics.
brinkwoman: Any discussion of the different aims of this roadmap.
MichaelGordon: Useful resource, but probably not our workplan as others are working on some of the topics. Maybe workplan in the sense that we may want to influence the work.
MichaelGordon: The categorisation is super useful.
jtandy: It is clear to include items that are time-expired. But do we include topics that are in active use?
tidoust: Probably a matter of finding the right label for them.
tidoust: The label "Features not covered by ongoing work" is not clear
tidoust: We need to include a rationale why some standard is "not webby enough"
<MichaelGordon> https://github.com/w3c/sdw/blob/gh-pages/roadmap/non-webby-ogc-standards.md
brinkwoman: I will come up with a better label for "Features not covered by ongoing work".
AndreaPerego: Just wondering on the services. The current WMS/WFS can be made webby using proxies just as shown with ldproxy.
brinkwoman: We are just looking at the specs and it would be up to the maintainers of the standards to figure this out. WFS 3.0 would be web-friendly, WFS 2.0 isn't.
AndreaPerego: The important point is that you can change without changing the underlying infrastructure.
AndreaPerego: We did something similar to ldproxy with a proxy on CSW in the GeoDCAT-AP development.
brinkwoman: This roadmap is just meant as a short list without detailled discussion how to make the standards webby. The Best Practices have some more detail.
tidoust: In addition to changing the label, also add a sentence why they are not web-friendly or how they could be made web-friendly.
(agreement that the roadmap should remain short and easy to maintain)
<AndreaPerego> +1 also from me
brinkwoman: I will go through the list and update based on the discussion.
tidoust: The categorisation does not work as natural as in the media example.
brinkwoman: "represent" is much larger than the rest, partitioning in "transform" raised eyebrows
MichaelGordon: For a data publisher the categories make sense
ChrisLittle: Sometimes it makes sense to manage metadata with the data, sometimes it doesn't; the split does make sense
<Zakim> AndreaPerego, you wanted to ask whether O&A cannot be considered as at least partially covered by SSN
AndreaPerego: I see O&M is shown as out-of-scope, but it is at least partially covered by SSN
brinkwoman: Yes, that needs to be made more clear, also the split between O&M and OM-XML
<Zakim> jtandy, you wanted to suggest “write spatial data”
jtandy: How about changing the represent category to "write spatial data” (capture-write-publish-transform)
brinkwoman: Agree.
<ChrisLittle> +1 to 'Write' instead of 'represent'
brinkwoman: Back to "transform": The tiling does not feel right in "transform".
MichaelGordon: High-performance computing may be another reason for partitioning
ClemensPortele: Partitioning is more about organising the data. In the tiling approaches, the same feature can be included in multiple tiles at different levels, for example.
jtandy: Maybe we do not need the category and can move the current entries elsewhere.
jtandy: Data cubes could move to "write". Is it well-deployed? How do we measure it?
tidoust: The "current implementations" metric only makes sense when the information can be harvested.
(discussion about how to determine usage statistics)
MichaelGordon: i3s/3D Tiles should go to "publish"
MichaelGordon: Use Mapbox Vector Tiles instead of the T-13 Vector Tiles ER
jtandy: QB4ST is "write"
jtandy: EOQB is "publish"
jtandy: Actually, it is probably "write".
(WPS could be added to "publish" or "write".)
brinkwoman: Good, now I can remove the "transform" category.
https://github.com/w3c/sdw/projects/15
ChrisLittle: (presents slides that cover both new projects topics)
ChrisLittle: s/projects topics)/project proposals)/
ChrisLittle: (explains history of table driven data formats in the Meteo domain)
ChrisLittle: For any given property there is probably a whole set of statistical elements for that property. How long can we keep adding additional elements to the lists?
ChrisLittle: Proposal 1: Simple Stats Ontology
ChrisLittle: Proposal 2: Statistical time periods
ChrisLittle: Any feedback, volunteers?
jtandy2: Is proposal 1 about an ontology or a controlled list. Probably the latter? (shows a WMO code table)
ChrisLittle: Yes, a starting point, but just from the WMO community and needs more input
tidoust: Why would we need to redo this work outside of WMO?
ChrisLittle: There is no awareness outside of WMO on this work.
tidoust: Maybe simply highlight this as an example?
Chris: In our own projects we have made up our own parameters as we needed them.
jtandy2: The two project proposal in the queue, how are they related? #1067 is part of the second proposal, the dicing of #1068 does not seem to be covered in Chris' proposals.
jtandy2: Any appetite for working on a controlled vocabulary from proposal 1?
jtandy2: Not seeing any volunteers, can Chris raise this in the OGC Statistical DWG once it is formed?
ChrisLittle: Yes
tidoust: It could also be included in the Statistical data on the Web BP
(break)
michaelgordon: future work ideas arising from the implementation reports:
… would like more implementation reports. 4 or 5 would be good
… OS will produce one
… Chris Jarvis from UK Environment Agency is thinking of producing one
… Is there anyone else in the room who could produce an implementation report, or are there others we could ask?
jtandy: it's fine if some implementation reports don't cover all best practices. It's not required to apply every BP in every application
clemens: it's best if the reports refer to operational services, rather than experimental projects
jtandy: Ed Parsons previously suggested that a package of implementation reports could be summarised for an article as part of the communication activities (prob not a scientific journal paper)
michaelgordon: there is a template for the implementation reports in Github. Will make sure it's in the main branch and appropriately named
example here: https://github.com/w3c/sdw/blob/gh-pages/bp/BP-implementation-report-00003.md
jtandy: anyone (maybe related to JRC) that could do an INSPIRE related implementation report?
michaelgordon: other work items arising from earlier included:
… comment to the DXWG on proposed DCAT changes
clemens: will write an email to them, commenting on the pros/cons of describing services as well as datasets in DCAT
hadleybeeman: DXWG is picking up some open issues from the Data on the Web Best Practices group. The DWBP group has been finished for a couple of years
michaelgordon: [extra work items] BP2 - use cases of indexing each spatial thing
… may want to engage the search engine providers on that. Will tag Ed Parsons on that
… BP14 (positional accuracy) has not been implemented in any of the 3 reports so far. Is there anything around use cases or implementation requirements that might help implementers do something with this
jtandy: we may want to categorise accuracy rather than use numerical values
michaelgordon: in Fort Collins F2F we discussed producing a cookbook of steps to take to implement SDWBP. Not had time to make progress on this yet, but could look at identifiying common things appearing in the implementation reports
jtandy: yesterday Chris Jarvis was saying he has a whole bunch of agricultural datasets to publish. Perhaps we could ask him/Swirrl to document the process of publishing as they go through that process, which could fit into a cookbook
tidoust: in the original BP document there was a section on gaps in current practice. Should we plan some work to fill in those gaps?
brinkwoman: there is a proposal to do an IETF RFC on coordinate reference system content negotiation - which was one of the identified gaps
michaelgordon: there is a related issue on providing different levels of precision of geometry description
tidoust: volunteers to create some github issues to document these things-to-do
chrislittle: an email came in to the mailing list today about what is the best practice for specifying the area of something?
jtandy: let's make a github issue for that
jtandy: thanks Michael for all the feedback on implementation reports
chrislittle: Rob Atkinson did some work in the SDWWG to produce the QB4ST ontology, to describe data cubes that had x,y,z,t dimensions
… you then often have a requirement, common to many OGC standards, on how to partition data - tiling, paging, ...
… my data is too big to handle at once, can I have it in chunks
… there is a general pattern here, not restricted to 2D tiles. There could be an ontology for data cubes to describe the underlying semantics for partitioning data
… There are a number of ways you could do this: one option could be for n-dimensional 'image' tiling approaches. Another option might be to do it by size of page. Or give me the first million values...
jtandy: the Linked Data Platform group did some work on this.
jtandy: presumably WFS3 has some approach to paging?
clemens: yes, mandatory to provide paging in WFS3
jtandy: there is a question of separating the concerns of data delivery and data representation
jtandy: should this be addressed to the OGC interoperability programme?
Michael_Jacoby: do you just need a query language?
chrislittle: with the RDF data cube as it is, you can only slice things
clemensportele: there are 2 separate concerns and it is probably sensible to keep things separate. One is the query language/approach and the other is the delivery mechanism
… often people use 'next' links in APIs for non-trivial data structures
chrislittle: sometimes it's not obvious what comes 'next' in a multidimensional query language
clemensportele: in the case of features, often the first page is useful
billroberts: some cases are nontrivial. There is not always a natural order of the dimensions, but you'd need that in paging
... the selections people want are doable in sparql, but hard to provide a good UI for that
...wondering if its more a question of representation design of your data, or API / query design
...it's a common problem, but for a lot of use cases it would need a query-based solution
<Zakim> jtandy, you wanted to ask if the ‘ontology’ is to describe the ‘pages’?
chrislittle: pre-defined partitions could make the queries more tractable
… particularly for the kind of very large datasets in use at the Met Office
jtandy: let's follow that up with examples of met office data
jtandy...reviews other things remaining on the agenda
mmocny: examples of publishing full 3d geometry of buildings?
michaelgordon: there are some examples from Germany
clemensportele: several cities have published a lot of their building data as 3d geometry
<brinkwoman> https://www.citygml.org/samplefiles/
RobSmith: can we have a group photo?
RobSmith: WebVMT uses an XML format, based on how WebVTT works. Francois had suggested that a JSON format for WebVMT might be a better choice
… but at TPAC heard news that WebVTT is not being taken forward beyond Candidate Recommendation, because there was only one implementation
… and the work had stagnated
… so which format would be best for WebVMT?
tidoust: my suggestion on JSON vs XML was around considering outcomes: if you want to have something appearing in an application,then it makes sense to follow WebVTT as it is supported by browsers. (TTML is not). WebVTT is a text based format, which can embed some XML. Parsing the XML parts is harder to do in Javascript than JSON
… XML in WebVTT was not meant to be a proper markup language, but just a syntax for some marked up elements
… it might be worth implementing it as an extension of WebVTT then it could benefit from their efforts
RobSmith: that helps answer the question and sets some context
… since there are JSON and XML versions of timed text, would it be practically or politically useful to have both
tidoust: some broadcasters have official approval for TTML for captioning format, but WebVTT is not. So media companies have tended to prefer TTML
… but that problem is not so relevant for WebVMT.
… suggest not mixing up formats
RobSmith: thanks!
<ChrisLittle> Thank you chairs, scribes and Francois
jtandy: [wrapping up and thanks]
Meeting closed