F2F Discussion in Amersfoort with EuroSDR, PiLOD, etc.

MEETING STARTS

Jeremy: The SDW WG was introduced in the plenary session. We collected some topics that may be relevant for discussion ...
... sw architecures used ...
... which formats, which types ...
... what prevents you from using spatial data in your organisations ...
... we have been trying to structures the BPs around a specific use cases. If you have real examples to share, please do ...
... tell us what is missing.
Chris: OGC changed the policy about who is the target public, and also non-members can influence the process.
Jeremy: Maybe we should do a tour-de-table to know who's here.
Linda: Work at Geonovum, and involved in SDW WG
Ed: Co-chairing the SDW WG, work at Google
??: GIS consultant and specialist. I would like to contribute to the BPs by experimenting and testing
??: Want to learn at Linked Data, and know how a book will look like in the future
??: Focus on publishing data in a way people can understand. Work on one of the Geonovum testbed
??: From Norway, work with OGC standard, but also sensor web. Currently more focusses on WFS. Find it difficult to navigate from a complex XML file by using tools users use.
Chris: Meteorologist at MetOffice. Interest in how to make 4-dimensional data
??: Work at Geonovum and very interested in what you're doing
??: PhD student at IGN France, work on linking geo data on the Web
??: From IGN France, very curious on the BPs, especially wrt spatio-temporal data, multidimensional data. This approach may bring new opportunities wrt the traditional approach.
??: Web cartographer and developer. Work for Amsterdam municipality, people knows everything on geo data, but not much on scripting and APIs.
??: Worked on integrating information from different perspective, covering geo but not only - e.g., CAD. Interested to see how all these "spatial" aspects can be brought together.
Phil: From W3C, coordinating the SDW WG.
Jeremy: Work at UK's MetOffice.
Paul van Genuchten: From Geocat, taking care of GeoNetwork, we are integrating a lot of webby things. Participating in the testbed.
Jeremy: BP is just one of the deliverables.
Ed: This is actually the 2nd deliverable, but gives the contex to what we have been doing. The first one was the UCRs, edited by Frans and Alejandro...
... the other deliverables focussed on specific ontologies - Time, SSN, Coverages (any data in time and space, very much used in the GIS world).
Jeremy: About the scope...
... three ways of interacting: being a member of the group, drop a mail to the mailing list, use GH to submit issues ...
... there are 5 themes, reflecting how we think about the problem space.
Ed: One of the challenges we are trying to solve is to identify those BPs that can be easily implemented, and those that can be considered advanced features.
Jeremy: The first problem is the assignment of identifiers. There's some discussion on whether identifiers can be assigned to real-world things or only to information resources. We try to give some advise on how to assign IDs to things...
... but to be actionable on the Web these IDs need to be HTTP URIs.
Jeremy: We are also trying to explain why you have to do it, and which are the possible advantages...
... the point is that the BPs must be durable. It is difficult to understand whether or not to give people technical guidance, since in the near future these technologies may be out of date
??: Why not putting BPs in a menu, ranked wrt the 5-star criterion.
Jeremy: That's a good idea. We also recognise that people start from different positions, so we may need to reflect this in the BPs.
??: Yes, but if the content of the BPs is made somehow visible (e.g., in a visual way) this can help people pick what they need.
Jeremy: Another good point.
Jeremy: But do you want concrete guidance, or not?
Ed: We can have both: an abstract description, complemented with an example on how this can be implemented by using a given technology.
(Many): Agree, concrete examples are needed
??: I recall a wiki having two sections, one that is fixed, and cannot be changed, and another one that is kind of working document.
Jeremy: But which platforms the examples should be taken from?
Paul van Genuchten: On of the issues is that people may want to do things, but they are short of fundings. It may be worth addressing the policy level, and not only the technical one.
Ed, Jeremy, Phil: agree
[gap]
Jeremy: So, you should provide examples of incremental approaches.
Jeremy: One of the options is about re-using authoritative IDs.
??: There is a possible disadvantange depending on who owns the data.
Jeremy: True, there are situations where you cannot / don't want to re-use existing data.
Jeremy: Another option is to re-use your local IDs...
... we give guidance on how to operate persistent IDs ...
... IDs for data slices / subsets ...
Paul van Genuchten: Why the last is not under DWBP? Is there something typically spatial?
Jeremy: This is indeed a general requirement, but the truth is that there's no mechanism defined for other data that can be re-used for spatial data.
??: We had to tackle with large objects (dataset items).
Jeremy: We have a section dealing with large data, but not on specific types (e.g., geometry)
Jeremy: Another BP referes to an issue mentioned during the plenary is that there are way too many ontologies, but eventually people don't use them, and prefer JSON/GeoJSON.
Ed: There's an open issue about not being to much focussed on RDF. We are not going to say that RDF is the only solution.
Jeremy: Another BP is about providing the right level of complexity and the right encoding depending on the use case / application. And in some cases you don't need to provide a precise geometry (e.g., the boundaris of the American West).
Jeremy: Another issue is about CRSs. A lot of Web people don't (want to) know about CRSs...
... Another point is about relative positions ...
... positional accuracy.
??: [explaining the use case about ability to refer multiple representations to the same resource] ...
... example is a building, described in XML, in a LD way, as a polygon on a map a CAD project. People relates them as the same thing, but this is not the case, because they are describing the same thing from different perspectives.
Jeremy: [moving on] Related points are make links visible on the Web, express relationship, making data indexable by search engine, link to the real things and not to their representations.
??: Do you link to other BPs.
Ed: Yes, the principle is not reinvent.
??: We should also prevent geo people from doing some things. People still thinks at geo data as maps, and, e.g., place textual labels as spatial objects themselves.
Jeremy: [issue added]
??: As a data publisher, you don't know who's using your data, for which use cases. It might be good to point to solutions that can be used to expose data in a way able to address the most common applications.
Paul van Genuchten: I have a problem with the word "publisher". This may give people the wrong idea that LD is only about data publication, whereas this should affect also how data are maintained internally (e.g., this applies to IDs / URIs).
??: Use case missing [missed it]
Linda: [addressing people from IGN] Do you use LD?
??: Just for research work, at the moment.
??: We are actually publishing the administrative boundaries of France. It's experimental, currently.
Jeremy: You can then help testing the BPs.
??: Accuracy, vagueness are key issues for us.

END OF MEETING

<scribe> Agenda: Ad Hoc

scribe; phila

<scribe> scribe: phila

Tour de table shows guests are mostly developers looking for guidance

Jeremy: Show the We Need You slide with some questions we're looking to answer
... Shows the BP doc http://w3c.github.io/sdw/bp/

Ed: Gives overview of the other deliverables of the WG

JT: Goes through the document.
... Begins with the audience section - who is this for
... Describes the Issue flags etc.
... Issues link to GH Issues
... Or can write to the mailing list
... Describes the 5 themes seen in the BP doc

Ed: Talks about incremental steps from small to 5* etc.

JT: Theme 1 - assignment of identifiers
... Gets dangerously close to HR-14
... So doc tries to give advice on what you should give identifiers to.
... Describes the structure of a BP
... Talks about difference between intended outcome and possible approaches to implementation.
... Do you want concrete implementation - which may go out of date - or do you want "create this outcome" but with less guidance.

Guest: In publication, we make a lot of use of flow charts.
... Maybe put in a chart with the different star levels and assign BPs to each one.

JT: That might work as it shows you where to start.
... We also have to think about different starting points, someone with an SDI cf. a Web Dev

Guest: When I got the book about Linked Data, I looked at the index and decided where I was going to start.
... A flow chart would have been helpful.

JT: Refers to DWBP which has used a visual method for navigation.

Ed: An abstract description cf. more practical

Guest2: Talks about low hanging fruit and bookmarking pages etc. The longer term vision is useful.

Guest3: I think you need both. You need more proven technology section and maybe a future-looking approach.
... A wiki in the airline industry where there are very strict regulations, and there's a draft section, and the sections are clearly delineated with colours etc.

Guest4: I think you need concrete examples for each BP.

Ed: We do have a clear internal vision that we want to help implementers to grab bits of code and start using it.

Guest5: If you're talking about code you need to talk about platforms etc.

Ed: Yes, and we recognise that any choice will be out of date in time.

Guest5: There is no one choice of today. JSON(-LD)? works on all platforms, it's a data structure, but be careful of choosing a development platform.

JT: If we were to choose a platform...

phila: W3C/Web Platform etc.

Guest5: I don't see examples

JT: Not yet...
... I want to come back to choice of platform. Do you want to see them in etrms of OGC services, or Python snippets.

Guest: We have traditional data providers, like governments, that we like to tickle to share their data on the Web. Only a minority will be tickled.
... There's the other groups that need regulation from above.
... You dopn't always target the data provider, you target the one above the provier to encourage them to push for change.
... You may need a differnet documentation approach.

Ed: You're saying it's more about policy and context?
... More the business case?

Guest: yes.

JT: Something that a manager can pass on

Ed: It can be more challenging to make the case for LD to policy makers who have spent a lot of money building SDIs.

Andrea: Another point might be - how can I implement this as a layer on top of the existing structure? What are the incremental steps? - useful?

Guest: I say from a tech POV, everything is possible.
... I find a layer on top of a layer may not be the best way.

Andrea: I was thinking of alternatives, that you can start from scratch, or slowly add bits.

Guest: Our experience is that companies like incremental steps that show benefits. And LD allows you to start small.
... You can guide comapnies towards this practice rather than enforcing it from above. benefits win over force.

Ed: There's a perspective we haven't communicated - beyond the SDI world, there is data on the Web that is not explicitly spatial that we can make explicitly spatial.
... We can say, if you're just building Web pages, how do you add a little bit of structured data to make location understandable.

JT: So we want BPs that say if you do this little thing, you'll see that benefit.
... BP2 is about pointing people to reuse existing authoritative identifiers. NL has URIs for dykes, buildings etc.
... reuse geonames, there are lots of IDs there. Network Effect.

ChrisLittle: We now have a target of no more than 4 links (facebook thing)

JT: There are situations where you can't use somebody else's identifier, but where you can, you should.

Chris: The first star, the licensing side - that's hard. We now have 2 categories: open data and open data that is managed - which you need to use responsibly.

JT: We say that you probably have IDs all over the place, but they're local ones. How can we help you create URIs from those local IDs.
... BP4 - changing over time, when tyo mint a new ID.
... Guidance on giving identifiers to larger parts of info.
... You may only want a smaller subset.
... This sparked a lot of debate (see https://lists.w3.org/Archives/Public/public-sdw-comments/2015Dec/0000.html onwards)

Guest: Why is this is the SDW, not DWBP?

JT: Because it came up looking at large spatial datasets/coverages. DWBP didn't come up against it and don't have an answer.

Ed: The heirarchy of places is relevant as well. One place is within another. Looking more now at placial, not spatial.

Guest: This is relevant to such a large audience, it needs to be seen from one angle and then work on others. Can you actually tackle the big topics.

JT: When we look at the broader problems, we do so through a spatial lens - or we'd never get it finished.
... Describes the how to test section. We want to yo be able to know if you've followed the BP.

Guest: You're talking about large datasets here. A topic we looked at in our research was looking at large objects, so at the entity level.
... Devleopers don't need to detailed accuracy that comes with some objects.

JT: We have a section talking about larger data, but not large objects.

issue: Need a BP on handling large spatial objects, i.e. with lots of detailed geometry. (BP doc)

<trackbot> Created ISSUE-39 - Need a bp on handling large spatial objects, i.e. with lots of detailed geometry. (bp doc). Please complete additional details at <http://www.w3.org/2015/spatial/track/issues/39/edit>.

JT: Talks about Expressing spatial data section.
... People use what they use. We want to try and provide clear guidance on what to do, including if you have a tool chain in place.

Ed: Draws attention to Issue-225, being too RDF-focussed.
... We're not going to say that the only solution is to use RDF.

JT: Some people will have heard of JSON-LD, a LD dialect that lets you get a long way into RDF without actually touching the Semantic Web baggage.
... Talks about BP6 - which will give us a way to give lost of differnet examples of how to do stuff.
... There is a spatial thing called 'The American West' - which doesn't have an agreed boundary.
... Not everything has to have a precise geometry.
... Talks about the importance of CRSs
... When you get to particular application domains, you might need a different CRS.
... BP9 talks about relative positions.
... 11 Talking about time.

Linda: Sander came to me with a use case that might give us a new requirement that might be relevant to the spatial relationships.
... They're trying to integrate data from different perspectives. One might talk about the properties of the building itself, others will talk about the representation of the thing.

Sander steps up to the white board...

Sander: I want to show why it matters that we have these relationships.
... Gives an example of a building with doors, windows.
... And we have an info-source that might be an XML doc
... Has IDs for the building, the door, the window.
... And there might be a map that shows the polygon that represents that building.
... This is the kind of data we work with for construction companies.
... Come say we have a LD approach with classes for the building, hasPart Door etc.
... Talking about tangible objects
... But others would talk about XML elements with attributes.
... We need a property to say we're talking about the same thing.
... Something that says I know these things are expressed differently but they are about the same thing.
... We need to bring these things together in a way that makes sense and we can't use owl:sameAs
... ArcGIS uses a table to represent things and people will say that a cell in the table is the same as the thing itself

Ed: In the GIS world, everything is digital, we didn't make the link to the real world.

Sander: With LD, people see that you can link thing, but if we want to crawl data and link it, we need to be clear what the differences are.

Ed: Gives his door lock example

Linda: Not everyine in the WG is convinced that we need to address this.

Sander: It's not for me to say whether it's for this WG to tackle.

Guest: Are you talkking to the lock or the wi-fi card in the lock?

JT: We're beginning on this journey with a plan to say that you need to identify real world things separately from data about them.

Guest: What kind of datasets are you working with?

Sander: We have designs, the building process, maintenance - lots of moments of data needs. For design, we're talking about CAD. Spatial info we're talking about location of course, this plot of land etc.
... relations to otehr areas of land.
... And then there are aspects such as validation - whether the buildings meet regulations etc.
... Do the objects fulfil the needs we extablished. Differnet people, differnet tooling, differnet priorities.
... These need to be brought together for the owner of hte road/building who needs all those things.
... We want to be able to say more about all those things.

guest: Why don't you use the standards of the building sector?

== Discussion ensues==

Sander: everyone has their own standards. merging them is difficult when you want to understand different aspects.

JT: calls time out
... The data integartion one is one we need to include.
... The specific case would be a lunch time discussion.
... Runs through remaining BPs quickly

Sander: Are you linking to other BPs such as self-describing APIs etc.

Ed: We want to avoid creating anything new if we can avoid it.

JT: Please point them out to us and then we can use them - don't assume we're going to do the right thing.
... Returns to his initial questions about software architectures, formats etc.

Guest: There are things that we should try and stop people doing. Like people using points with a label, but when you zoom in it all goes wrong.
... People think of spatial data as maps - that's the problem.
... On people's desktop, it works. But instead of having an annotation it becomes anotehr spatial object.

issue: Making sure that attributes on maps, eg labels, are not traeted as spatial objects themselves.

<trackbot> Created ISSUE-40 - Making sure that attributes on maps, eg labels, are not traeted as spatial objects themselves.. Please complete additional details at <http://www.w3.org/2015/spatial/track/issues/40/edit>.

linda: We need examples and I was wondering whether Edward could provide such examples for things that change over time.
... is it going to be persietent? Can we link to it?
... We're talking about a Web site that lists all the Dutch municipalities that exist and those that used to exist.

Guest: The hard thing in general is that publishers don't know waht their data is being used for, so you need to be flexible in what you provide.
... Might be intersting to promote things like aggregation, faceting, to make data more accessible.
... It also relates to the size of geospatial datasets. A list of all restaurants in NL is long. But if I only want certain types in certain areas, I don't want all that.
... If we can use these kinds of mechanisms this would help.

JT: That gets us into subsetting.

BartvanLeeuwen: A large part of what you're saying is/should be covered in DWBP

Guest: Makes the point about the workd 'publish' - gives people the idea that LD is all about publication. Actually it's about *storing* data on the Web
... I really don't like the word publish in this context.
... People do a lot of transformation before they publish it as INSPIRE, rather than actually use INSPIRE.

Dog Food

Ed: WE also need to be aware of the flip case of that. We don't want to require people to publish all their data.
... It's obviously easier if you use the same IDs inside and outside the firewall.

issue: Don't rely on the word 'publish' - it's about storting data on the Web (BP Doc)

<trackbot> Created ISSUE-41 - Don't rely on the word 'publish' - it's about storting data on the web (bp doc). Please complete additional details at <http://www.w3.org/2015/spatial/track/issues/41/edit>.

JT: We are keen to have examples of stuff you're doing in the wild. So thank you - please let us know.

Guest: You're talking about your use cases. We make books - we're struggling to use Top Braid Composer, linking different parts of our system.

JT: Talks about the BBC Linked Data Platform.

Linda: What is IGN's interest in LD?

IGN: We have a lot of interest in it for our research proposals. We've done a lot but it takes time. We're discussing use of URIs as IDs
... Some people are afraid, whether they have to be dereferencable or not etc.
... Talking about interlinking. I'll be presenting something on this later today.
... We are publishing the Administrative units on France as LD, accessible via a SPARQL endpoint.

JT: So you'd be in a good position to road test the BPs
... is this doc accessible to me? Does it help me?

IGN: Issue of accuracy, merging sets at different levels of granularity.

Ed: We're not going to solve fundamental problems of spatial data - we might just raise a warning flag.

JT: Draws the meeting to a close.