Spatial Data on the Web WG F2F, TPAC 2016 Day 1

<eparsons> Morning all - We are working on getting the webex to work with the room ... please wait than you

<AZ> hello

<trackbot> Date: 19 September 2016

<kerry> scribe: Armin

<kerry> scribenick: ahaller2

<AZ> AZ = Antoine Zimmermann

Ed: begins with a tour de table

<fasr> fasr = Francisco Regateiro (Lisbon University)

<scribe> scribe: ahaller2

<scribe> scribeNick: ahaller2

<eparsons> https://www.w3.org/2015/spatial/wiki/Meetings:F2F4

eparsons: going through agenda

<eparsons> https://www.w3.org/2015/spatial/wiki/Patent_Call

eparsons: patent call

<frans> overview of recent changes in the UC&R document: http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SPWD-TPWD

frans: UC&R introduction
... some changes to requirements have been made

<frans> https://www.w3.org/2015/spatial/track/products/1

frans: 6 possible upcoming changes
... other subgroups should be aware of these new requirements

eparsons: are there any requirements we can close now?

frans: more that people are aware of them

kerry: let's work through the list of requirements

frans: issue-75

<phila> issue-75?

<trackbot> issue-75 -- quality metadata out of scope? -- open

<trackbot> http://www.w3.org/2015/spatial/track/issues/75

frans: quality for each set of data point may be needed

kerry: quality indicators can be modelled in SSN

<Zakim> jtandy, you wanted to ask if the requirement is a little more generic ...

kerry: SSN will be linked to Coverage which is one requirement
... in my opinion, it is out of scope here

jtandy: data acquisition may be another use case where you attach metadata to a data point

<Zakim> phila, you wanted to talk about DQV

jtandy: i have not seen a common practice how to attach metadata to the data point
... for example, someone says the flood water has come to their house. it would be useful to see metadata attached to that.
... attach metadata to a dataset record

kerry: it is a pattern, not an ontological requirement

phila: I don't think it is out of scope
... we don't have to do it ourselves, other working groups have done that

<phila> DQV

phila: it is in scope, it is important to talk about accuracy and precision. It is important for the editors for those deliverables to include examples how to use it.

<Zakim> ericP, you wanted to say that clinical sometimes relegate uncertainty to extensibility mechanisms have lots include stuff like at-least or at-most in the core

billrobe_: identify individual data points might be a requirement too.

ericP: clinical domain, where it was very important to talk about quality of data

eparsons: we could close issue-75 by saying it is in scope

frans: do we have a crowd-sourcing use case?
... use case to attach metadata not for datasets, but for individual data points

RESOLUTION: Issue-75 is in scope, close issue-75.

<BartvanLeeuwen> +1

<eparsons> +1

frans: make it a requirement for best practices, potentially also for SSN

+1

frans: Issue-70

<phila> close issue-75

<trackbot> Closed issue-75.

<phila> issue-70?

<trackbot> issue-70 -- Add a requirement for avoiding coordinate transformations? -- open

<trackbot> http://www.w3.org/2015/spatial/track/issues/70

https://www.w3.org/2015/spatial/track/issues/70

frans: I don't think anyone is opposed to this requirement

eparsons: can we talk about the wording
... putting a huge effort on the publishers, realistically we don't project data to multiple coordinate reference systems

ByronCinNZ: default CRS should be the fall back

<frans> proposed requirement: *Requirement: *Data consumers should be helped in avoiding coordinate

<frans> transformations when spatial data from multiple sources are combined.

billrobe_: in practice we talk about 2 CRS covering 99% of the use cases

<Zakim> jtandy, you wanted to suggest that we're missing a best practice for publishing in multiple formats and representations?

billrobe_: the publisher taking work of the user is a good thing

jtandy: if you publish in the CRS of your national agencies requirement, look at your audience and decide if you can publish in multiple CRSs, e.g. your national and mercator
... if you can afford it, do it

eparsons: finesse the wording here. publish in multiple CRS to meet your user requirements
... e.g. if you are in Britain, publish in British national grid and another one

frans: we need to keep the requirement phrased as a requirement, not to propose a solution
... one solution is to publish data using multiple CRS, but we should not include that in the requirement

<phila> phila: Notes BWBP 14 https://www.w3.org/TR/dwbp/#MultipleFormats

<phila> phila: As many users as possible will be able to use the data without first having to transform it into their preferred format.

kerry: the publishers are our users as well. We should make the life easy for both.
... how to we identify the CRS and is there a default CRS?

<Zakim> jtandy, you wanted to agree with Frans

jtandy: there is never to be a default CRS
... we can't make a reference to a coordinate without a CRS!

phila: best practice 14 from dwbp
... as many people as possible will be able to use the data without transforming it

https://www.w3.org/TR/2016/CR-dwbp-20160830/#MultipleFormats

ericP: encouraged to publish in standard format is always a good best practice
... if there is a publisher who does not use the standard format, a third party can come along and do the transformation

eparsons: can we close that issue?
... pass it on to the best practices requirements

<phila> PROPOSED: Close issue-70 that we need to pass this on to BP to handle, encouraging publishers' need to meet broadest possible community

<AndreaPerego> +1

<eparsons> +1

RESOLUTION: Close issue-70 that we need to pass this on to BP to handle, encouraging publishers' need to meet broadest possible community

<ByronCinNZ> +1

<AZ> +1

+1

<phila> close issue-70

<trackbot> Closed issue-70.

<phila> issue-74?

<trackbot> issue-74 -- That uom and precision and accuracy should be covered in ucr and bp (and respected in other deliverables too) -- open

<trackbot> http://www.w3.org/2015/spatial/track/issues/74

frans: issue-74
... current proposal is to have unit of measurements should always be included in observations

<Zakim> phila, you wanted to dig into "unit of measurements should always be included in observations"

phila: dwbp, uom should be included, but not in the string, but as a separate attribute

danbri: in schema.org we have some workarounds
... space between $ and price, but it is not a best practice as such

eparsons: wouldn't the uom not be part of the metadata of the dataset

kerry: it is very particular kind of metadata. If you have spatial data and you don't have the uom, it is useless. So it is essential metadata.

<AndreaPerego> There's an example in DQV on the use of UoMs for data accuracy and precision: https://www.w3.org/TR/vocab-dqv/#ExpressDatasetAccuracyPrecision

<phila> PROPOSED: That it is q requirement to have UoM included

<eparsons> +1

<BartvanLeeuwen> +1

<jtandy> +1

<Linda> +1

<billrobe_> +1

+1

<AndreaPerego> +1

<ByronCinNZ> +1

RESOLUTION: That it is a requirement to have UoM included, close issue-74

<kerry> +1

<phila> close issue-74

<trackbot> Closed issue-74.

<frans> issue 74 proposal 1: We expand CRS definition requirement a bit to make it clear that a CRS definition should include an indication of UoM. For instance:

<frans> "There should be a recommended way of referencing a Coordinate Reference System (CRS) with a HTTP URI, and to get useful data about the CRS when that URI is dereferenced. The CRS data should include the unit of measurement of the CRS."

<frans> issue 74 proposal 2: We add a new requirement:

<frans> "The use of precision that matches uncertainty in coordinate data should be facilitated and encouraged"

issue-76?

<trackbot> issue-76 -- New requirement for multiple CRSs? -- open

<trackbot> http://www.w3.org/2015/spatial/track/issues/76

<phila> issue-76?

<trackbot> issue-76 -- New requirement for multiple CRSs? -- open

<trackbot> http://www.w3.org/2015/spatial/track/issues/76

jtandy: there is no requirement to have multiple CRSs, but data should be accessible, which could be multiple CRSs

kerry: it is same as issue-70

<ericP> issue-70

<trackbot> issue-70 -- Add a requirement for avoiding coordinate transformations? -- closed

<trackbot> http://www.w3.org/2015/spatial/track/issues/70

jtandy: geojson does not support multiple representations of the same data
... so you split data out in different representations

ericP: 70 says to minimise transformations, 76 is a solution to that
... rephrase 76 to make it a requirement

frans: to publish multiple CRS can have different reasons, i.e. to follow standards, not just to make it easier for users

<kerry> +1 to eric's comment -- make sure issue 70 is just phrased right

eparsons: close 76 and it is 70, but rephrased

frans: publishing in multiple CRS is already a practice, but they don't know what the best practice is

<phila> PROPOSED: Issue-76 is close enough to issue-70 that we can cover it in the way we closed 70, although there is a difference in perspective

eparsons: close enough, they will both be covered in best practices document

<phila> PROPOSED: There are cases where there is a requirement for more than one CRS, so we can close issue-76

<eparsons> +1

<RaulGarciaCastro> +1

<BartvanLeeuwen> +1

<jtandy> +1

+1

<ClemensPortele> +1

<ByronCinNZ> _1

<AndreaPerego> +1

<ByronCinNZ> +1

RESOLUTION: There are cases where there is a requirement for more than one CRS, so we can close issue-76

<phila> close issue-76

<trackbot> Closed issue-76.

<eparsons> Coffee break back at 10:30 local - 15mins form now

<eparsons> Slowly returning...

<kerry> scribe: kerry

<scribe> scribenick: kerry

<RaulGarciaCastro> I’ll come back after lunch

<ByronCinNZ> Yes

<jtandy> BTW: the summary of SDW bps is here - http://w3c.github.io/sdw/bp/#bp-summary

<jtandy> agenda for the BP session is here https://www.w3.org/2015/spatial/wiki/Meetings:F2F4#Monday

jtandy: topic: best practice
... we don't have time to cover all 17 issues. please help to priorities
... thankyou for all the expert opinion so far -- but tricky to distil into workable bps
... linda nad I have bben working hard on this but it is harder than we expected
... abd we have less time to devote going forward
... we can still do edit and style and steer and rank, but we need WG members to own sections of the doc (a BP)

<Zakim> phila, you wanted to talk about engagement

jtandy: think of this as you can volunteer for a BP topic

phila: people read the doc getting close to publication , as i have on the plane here
... see kadvice from bernadette

bernadette: one person read the whole doc at a very late point and made a *lot* of comments which were helpful but took a long time to process
... it is really important if people read the details before the last minute ..
... we had text that had been there right through that then got questioned right at the end.
... we had to have meetings on specific points that were raised, the doc got much better
... but it is important to read t he details asap is better

jtandy: and specific targeted meetins with the person raising the issue

bernadette: also good was f2f to foucs

jtandy: and you got the WG to comment on particular BPs, but it all comes in a rush at the end

phila: in theory we need to every thing finalised right now -- time is running out

jtandy: until 12:30 need to shake down best practices -- which are the least clear and/or most important?
... linda is preparing a tally -- which has top priority to nominate of the 17?

clemens: bp 1, bp 7, a missing one on using complex iso models and how to translate to rdf json and others -- how do we advise data publishers on this?

ClemensPortele: is there a simple solution? Needed for inspire.

billrobe_: 4, 7, 8

eparsons: 4, 7 ,14

BartvanLeeuwen: 4,7,14

AndreaPerego: terminology: spatial thing, features, and its effect on the draft ontology

<eparsons> Note hadleybeeman

s/spaatial/spatial/

AndreaPerego: 7

frans: 8 and 9

Linda: 4, 7, 8

jtandy: 9 (fuzzy boundaries),, 7, something on crowdsourcing

<Linda> any voters on webex?

hadleybeeman: process question: are you planning implementations?

jtandy: we plan to point to implementations in the wild -- but we may have trouble finding some

hadleybeeman: are you separating existing form not yet existing?

jtandy: we expect to indicate that -- things will not be "proper best practices" if not implemented in the wild

ByronCinNZ: 3, 4, 9 but if we are doing 3 anyway i vote for formats (8)

<ByronCinNZ> Yes 8

AZ: 7

jtandy: so we will do top 4.

Linda: 7, 4, 8, 9

jtandy: 20 minutes on each

<jtandy> http://w3c.github.io/sdw/bp/#globally-unique-ids

<phila> BP7

jtandy: pls read the bp for number 7 now
... there is also a meeting thread

<jtandy> see email summary for BP 7: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0139.html

<jtandy> ahh - that was the top of the thread ... I'm finding the summary now

<jtandy> summary = https://lists.w3.org/Archives/Public/public-sdw-wg/2016Sep/0096.html

BP number 7 http://w3c.github.io/sdw/bp/#globally-unique-ids

eparsons: need some context, e.g. explaining that now you need to publish stuff at a finer granularity that you are used to
... when we publish we need that every thing/feature/atomoc piece needs an identifier

<jtandy> http://w3c.github.io/sdw/bp/#how-to-use

jtandy: I was trying to to unpack that conecept here http://w3c.github.io/sdw/bp/#how-to-use
... so here's your starting point

<ByronCinNZ> Lost audio

[phone dropped out ... messing around trying to fix]

<ByronCinNZ> Thanks

<jtandy> and the identifiers context is provided here: http://w3c.github.io/sdw/bp/#what-r-u-talking-about

<AZ> audio back

<ByronCinNZ> Cheers

jtandy: ... in irs is link to what are u talking about -- context for identifying -- is that the context we need?

eparsons: yes, but we need bits of it restated again within the relevant bp presenation: this will be very new for SDI audience although old hat for web people
... will laso apply to other BPs where a fundamental change is recommended

<Zakim> ClemensPortele, you wanted to talk about "Reuse identifiers when you can"

ClemensPortele: reuse identifiers when you can -- how is this going to work?

e.g using dppedia or geonames for the uir, but i want to publish something else -- if you retirve the uri you will not come to my information that i am publishing

s/iur/uri/

ClemensPortele: so my publishing will still be dark becuase noone will come to it

Linda: responding to ed -- is the "why" section of bp not good enough?
... e.g. BP 7 starts with heading "Why". What is missing?

eparsons: the granularity in particular, not just and enpoint for a wfs, but every object there

Linda: so if you are used to using wfs -- this is how it is different

eparsons: addressed to particular users -- highlght how this is going to be different for you.

jtandy: examples will help with this

billrobe_: on ClemensPortele point about identifiers,
... it depends on your data model and say you are doing datacube you do want someeone else's identifier so that you can interoperate
... one very useful case is the n-ary relations wheret ehe place is the object of the statement

<danbri> hmm https://en.wikipedia.org/wiki/Smeaton%27s_Tower "Smeaton's Tower is the third and most notable Eddystone Lighthouse." -> https://www.wikidata.org/wiki/Q3995634 50°21'51.8"N, 4°8'30.5"W vs https://en.wikipedia.org/wiki/Eddystone_Lighthouse -> https://www.wikidata.org/wiki/Q546122 50°10'48"N, 4°16'12"W

ByronCinNZ: in realtion to data on the we bp, in our case we need the spatial things themselves

jtandy: dwbp has 2 cases, , thes second is item-level

phila: adwbp a lot of the examples use it as well
... noone is going to store full uris as a waste of space -- it may not be stored as a uri but must be translatable to one easily

ericP: could be a relative URI so properly managed

AndreaPerego: responding to phila , in geospatial catalogues we have unique uids, these can be added to a base uri, is this ok?

<Zakim> danbri, you wanted to ask about syntax (e.g. json-ld would allow foo:bar qualified names, other contexts allow gzip, ...)

danbri: what syntax ? can have different abbreviations depending on sytax
... can rely on storage tool

<danbri> another e.g. if you're in an XHTML regime you could use entities; in JSON-LD qnames or however JSON-LD calls qualified names.

eparsons: so the best approach is syntax-specific, but the general idea is the same and we need to force the issue

jtandy: content we are heading the right direction
... billrobe_ what are you specific issues?

billrobe_: BP mostly covers it ... item 3 "stable identifiers" is a complex modelling problem to decide if it does change (e.g. boundaries change and sometimes that is critical) but this is covered in bp as it is

BartvanLeeuwen: agree with clemes becuase need a uri that resolves to what I want to say about it, and the way I want it resolved

<Zakim> phila, you wanted to panic a little

AZ: bp 7 is very important but i do not have a specific concern

Linda: we discussed indirect identifiers in mailing list which was almost resolved and should go here

phila: want to hear from dan, erric, hadley on this
... you do not want to use a goenames uri as the subject in your rdf?

ClemensPortele: yes, but not necessarily rdf -- i want my representation to be the target of resolultion

phila: ok, so you don't want geonames to be the response -- so should we recomment owl:sameas?
... can we use owl:sameAs?
... so maybe 3 people all point to anne frank's house

AndreaPerego: the point is also about provenance to know who is saying what, maybe this solves that

<Zakim> danbri, you wanted to discuss owl:sameAs being a very strong claim

ericP: don't want sameas as as it is not the same thing just in the same place
... want to addreess use case of a location and you need to make a decision -- you invent more predicates

danbri: what eric just said
... sameas is almost like swearing
... e.g. whiioch poland? and smeaton's tower is it hte same as edystone lighthouse?

phila: but there is aconnection and we want that reoirded

<AndreaPerego> Wonder whether rdfs:seeAlso could to the job instead of owl:sameAs?

eparsons: so anne franks house in my database (BP 14 and 15) linking my datababse of houses in amsterdam with bart's database of fires in amsterdam

<danbri> seeAlso is pretty weak, owl:sameAs is super strong, there are things also like skos mappings that sit along the spectrum between those

eparsons: I need to say that I have a consistent uri within my database (reuse is elsewhere)

hadleybeeman: but "reuse identifiers" is in here!

ClemensPortele: we have a different understanding of reuse

<eparsons> kerry : duty to create predicate "sameplace"

<ericP> kerry: i believe it is our duty to construct a predicate that captures samePlaceAs

ClemensPortele: bp 14 is establishing the links,, and that is different from...

<frans> sameplace could be one of the spatial relationships we need to have defined

ClemensPortele: we shouln't just look at OWL e.g. geosjson, e.g. scheam.org sameAs

eparsons: call for wap of scribes

phila: please read DWBP best practice 10 as it contradicts us

hadleybeeman: yes!

<phila> scribe: phila

<scribe> scribeNick: phila

hadleybeeman: If I understand you correctly, people are asying that they don't want to use other people's identifiers because you want to make your own statements about things

BartvanLeeuwen: One of the issues we have is, are we too RDF-centric
... If you put a spatial thing on a map, and people want to click it, then people can find out more.
... I want to create a page that says Anne Frank's house is on fire that it has interesting shutters etc.

hadleybeeman: But you're saying you want an ID for the fire at Anne Frank's House

jtandy: So Bart describes an incident that happens and Ed is describing the shutters..

hadleybeeman: Draws diagram of the house, its fire and its shutters
... But they're both about the same place

<ByronCinNZ> Yes I am here

hadleybeeman: You need diff IDs for the incident and the shutters but they're both about the same thing and for that we say use the same URI

billrobe_: Agrees with hadleybeeman and gives example. Also, we're not only in the RDF world, so the majrity of use cases work well with using some definitive ID for Anne Frank's House
... I can deliver my info about Amsterdam as HTML and RDF...

<hadleybeeman> Or CSV

<Zakim> ericP, you wanted to say that reuse identifiers is always great. also complicated, also worth reminding people, but creating the abstract relationships ducks the controversy.

jtandy: And then maybe use schema:sameAs

ericP: Some perspective... every BP in every environment says use URIs as IDs but the zeroth law is don't lie
... A little bit of ontology that allows you to say 'same location as' - people get to reuse IDs there. They're not encouraged to reuse IDs where they shouldn't
... Also get to avoid complex conversations...
... Coming up with hard and fast rules about saying two incidents are the same is very hard
... You don't want to get into worrying about why two things are the same

ahaller2: Eric said what I wanted to say. Same location as is the only predicate we need.

ClemensPortele: I'm worried about this strong 'same'. Many things in a map will have IDs, and finding 'the canonical identifier' is nigh on impossible and no one will do it.
... A more relaxed linkage is good

jtandy: I think we're concluding that we need a more relaxed relationship for this. Maybe this is a missing BP
... We're saying that if you want to relate two things as being in the same place, we should show how to do it without necessarily using the same ID.

eparsons: I think that's BP 14 or 15, not 7

<danbri> proposal: https://gist.github.com/danbri/12cbbdb26cfa25a5bc6ac2060788766f (too long for IRC :)

frans: Spatial same as - in spatial data, we talk about spatial things and geometries. You have a well established system for saying geometries are the same

<kerry> +1 to frans remark

frans: Maybe we need a set of relationships for spatial things

jtandy: So the predicate that Kerry suggested... some sort of geometric calculus?

kerry: No, some sort of (non-computable) spatial relations.

<Zakim> hadleybeeman, you wanted to ask if "best practice" (vs normative spec) allows for this kind of fuzziness already

kerry: You know we talked about backlinks? This is where I think it's relevant

hadleybeeman: I hear you discussing this BP and it sounds as if you agree but you're looking for edge cases where it doesn't work. Does this being a Note help to allow some fuzziness?

jtandy: In GeoSPARQL - OGC is creating an ontology for this

hadleybeeman: Butr you're writing BPs which doesn't need to be as precise as a Rec

kerry: I don't think they're edge cases, they're normal

BernadetteLoscio: When you're talking about datasets and the items within them, the item is Anne Frank's house? Not stuff within it?

jtandy: Anne Frank's house could have a point, 2 or 3 D polygon

[More discussion of IDs for Anne Frank's House]

<hadleybeeman> [and assertions about Anne Frank's House]

-> http://sws.geonames.org/6618987/ Anne Frank's House

http://w3c.github.io/sdw/bp/#indexable-by-search-engines

<danbri> "Search engines should receive a metadata response to a HTTP GET when dereferencing the link target URI." … what is a link target URI?

billrobe_: We spent a lot of time talking about creating precise machine readable data about things that, AFAIK, search engines are ignoring.
... schema.org might be a route to providing something useful for search?
... Is there sometehing already in place that we can use in our BPs?

jtandy: We've suggested that schema.org provides a vocab that helps search engines index things like schema:Place
... Does that help search engines answer questions like find coffee shops near here?

danbri: Potentially
... schema.org works because it sits on top of what was in place already.
... RDF tried to build a parallel Web that ignored the existing billions of pages.
... If you express your data in schema.org, there's no guarantee it'll be used.
... I don't understand what a link target URI is?

jtandy: For a URL, if you defref a URL, you should get back an HTML page that might have embedded data
... but the granularity might change. You want a URL for everything in a WFS

ClemensPortele: That exists already

jtandy: But it's not crawlable

danbri: A lot of sites used to hide things behind HTTP POST
... I think the same thing happened around SDIs - things are hidden. You need to make a Web page, make sure robots.txt doesn't exclude it etc.
... Don't treat it as a special universe.

billrobe_: Makes sense, but it's not often practiced.

danbri: Content negotiation is a tricky one. Se Web loves it

ericP: JSON likes it
... It's a problem if the data is too large

ClemensPortele: In the Geonovum test, what we did was what we said here. We ctreated an HTML paghe for every resource that we had and included schema.org in that.
... the tricky part
... theoretically it's a BP, in the real world it's not exploited.
... We could't really argue that it made a big impact
... If we look at reviews, it's definitely a BP. But not really for everything.

ByronCinNZ: I feel like it's tryiung to say too much
... There's a lot in there that I find contentious-ish. A BP on fail metadata, well that's about keeping metadata up to date.
... Maybe it could be more succicnt. What actually is the point?
... Some BPs have really good examples
... could be more direct and more usable.

<danbri> for Google's use, see also https://developers.google.com/search/docs/data-types/local-businesses (opening hours oriented), https://developers.google.com/search/docs/data-types/events (events…)

frans: Should this BP not simply say, make HTML models of the data you provide?
... It you at least make HTML pages you've made progress on making your data search engine searchable.
... The other thing is linkage between the thing and the metadata
... I imagine a SE requests a page, looks for links and then follows those links
... What's required is a link from the data to the metadata and then links within that. Maybe to subsets and other subsets

<Zakim> danbri, you wanted to discuss w3c instruments

<ericP> [media-types] Review request for application/geo+json-seq media type registration

Linda: Like a sitemap

ClemensPortele: But sitemaps are limited to 25K links
... We had 8 million addresses

Linda: It can be paged

danbri: Is the word 'Best' correct. W3C likes to attract people to try out new stuff. It seems a lot of what we're talking about is new.
... I spend a lot of time trying to get people to make use of schema.org data.
... If all we can write is BPs then we're limited. If we can say emerging practice we perhaps can go further

eparsons: There's a heirarchy of BPs. There are simple things you can do, like exposing what's behind your WFS. Next step is to create HTML pages, next step is to add in structured data

<ericP> i believe hierarchies like this are expressed on coffee mugs

eparsons: i.e. take a stepwise approach. BPs can be incremental.

<Zakim> jtandy, you wanted to ask "is something _on the web_ if search engines can't see it?"

<danbri> I was just reviewing https://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices (2010). A lot of it is both precise and has survived the test of time. It updates even earlier work, https://www.w3.org/blog/BPWG/2010/12/14/mobile_web_application_best_practices_is_2 from https://www.w3.org/TR/mobile-bp/ (2008). Earliest I can find is https://www.w3.org/TR/2005/WD-mobile-bp-20051017/

jtandy: Is it on the web only if search engines can't see it? They only look at webpages

danbri: Nope, images, etc.

jtandy: Is the BP more along the lines of creating a human readable page and then maybe a structured version

eparsons: WxS isn't on the Web, it's on the dark Web

jtandy: If we want our data to be on the Web, people should be able to find it with a normal browser. Better still using some structured data as well (schema.org)

<Zakim> hadleybeeman, you wanted to talk about how this works for browser standards

jtandy: if we can encourage people to do that then the SEs might start to use it.

<eparsons> zakim close queue

jtandy: I think we've made progress with BP4, yes

phila: It's consistent with DWBP's advice on making (meta)data human and machine readable

Best Practice 8: Provide geometries on the Web in a usable way

-> http://w3c.github.io/sdw/bp/#describe-geometry BP8

jtandy: Proposes to take 60 mins for lunch
... Then we can pick up BP8
... Rather than try and rush it in 8 mins

hadleybeeman: On Best/Emerging practices...

<eparsons> Lunch at 12:30 - will be back at 13:30

hadleybeeman: We've been discussing this a lot in the TAG and whether W3C is where standards are created or ratified
... What the HTML Web Browser world is that for any new idea, they want it hammered out in a Community Group.
... They'll form a group within the Web Incubator Community Group
... So that by the time it's in a WG it's already in the wild
... Then WGs aren't working from scratch

[Discussion around future work, life of the WG etc.]

Discussion of difference between OGC and W3C in terms of end of work for WGs. OGC's carry on indefinitely, even in dormant, W3C has to start again

danbri: Can it transition to a CG

phila: Yes of course

<eparsons> Lunchtime everyone

[Adjourned for lunch]

<eparsons> Slowly returning from lunch...

<jtandy> so ... we're just restarting ...

<jtandy> in the room we've decided to try to complete the discussion on BP7 about "indirect identification" ... see summary of email thread at https://lists.w3.org/Archives/Public/public-sdw-wg/2016Sep/0096.html

<eparsons> Webex back I hope - can you hear us ByronCinNZ ?

<ByronCinNZ> Yes

<eparsons> Perfect thx

<ByronCinNZ> Will be jumping over to Orlando shortly for the DCAT metadata OGC. Will return after

<jtandy> for ref, see http://www.w3.org/TR/2004/REC-webarch-20041215/#indirect-identification

<billroberts> scribe:billroberts

<scribe> scribenick:billroberts

Indirect Identifiers

<DanhLePhuoc> pressent+ DanhLePhuoc

jtandy: summarises the ideas of 'Indirect Identification' based on the link above
... do people recognise this practice as useful and something that happens a lot?

<eparsons> billroberts Has not experienced any issues with indirect identification

<eparsons> billroberts metadata solves Last updated problem

danbri: schema.org has a vocabulary that is quite agnostic. You could use that rigorously in terms of differentiating identifiers and documents about them

<Zakim> danbri, you wanted to say two things: forcing thing vs page-about-it distinction everywhere comes with costs (for publishers and consumers); muddling up things with their

danbri: but you can also use it 'scruffily', using a web page about say Brad Pitt as a way of referring to Brad Pitt
... it was found to be hard to get the idea of distinguising web address and identifier to developers. It would be possible if there was a distinct benefit, but that probably isn't hte case. There isn't the incentive at the moment
... there is a cost to enforcing the distinction, and there is a cost to mixing them up. So you have to weigh up the pros and cons

<roba> hi - joined via webex but its behaving differently - not hearing anything and it offering a video session, no mic mute option.

jtandy: can we say that it's common practice to conflate the identifier and the document, and that's ok?

eparsons: we can say it's common practice for sure

kerry: but should we endorse it?

phila: it becomes a problem to use an indirect reference, if you use it in the wrong way
... eg to say the mountain is 374kb, but if you are saying something sensible in that context, then it causes no problems
... this is a widely used approach and it generally doesnt' cause problems

AndreaPerego: if your use case doesn't need the distinction, then don't do it

<danbri> All I was going to say: at this relatively early stage, when a given thing doesn't have a lot of machine readable Web descriptions, strict separation of thing-vs-description identifier is overkill. But once we have more adoption it may prove increasingly valuable.

<eparsons> billroberts depends upon context - relies on human - but thats ok

<phila> billroberts: We're agreeing that it depends on context and we're relying on the human operator to apply that context

<roba> q

<DanhLePhuoc> +q

frans: we can probably assume that people won't generally be confused about spatial things - i.e. they won't think it's a document

ClemensPortele: but we then may need to distinguish Spatial Thing and Feature?

kerry: how do we convey to a user of the data what we mean by a URI?

roba: one use case is citing an object. In that case you want an identifier for the thing, not a representation of it. If the data provider wants his representation to be cited, then you might have to make the distinction
... one possible way to do that is the URI redirection approach.

jtandy: do you mean something like a 303 redirect to a WFS endpoint?

roba: doesn't matter too much what you redirect to, you can just use the test on whether it is redirected or not
... it's like referencing a geometry not a feature

jtandy: tries to summarise and play back Rob's point. If you do redirect, you've separated out the thing and the representation

roba: not quite as strong as that.
... if it doesn't redirect, you could tell that the URL is not safe to be an identifier

jtandy: how much context do we need? how to express it?

roba: one approach is to get the context by dereferencing it, but I don't think we can say that is a best practice

jtandy: so, as Dan says, we're all blundering around

DanhLePhuoc: a data snippet can be valid and useful without having an http URI
... so could use non-http identifiers (URNs eg)

jtandy: I think we want to recommend HTTP identifiers, even if they don't resolve on the web

DanhLePhuoc: using identifiers that are not HTTP means that you don't have the cost of setting up a web server to allow dereferencing

<Zakim> phila, you wanted to talk about dumb strings

phila: URIs should be treated as dumb strings, you can't infer any meaning from them

<eparsons> billroberts redirects not practical for mass market users

kerry: also uncomfortable about using the redirect behaviour as a way of inferring context

roba: I think that's ok, but a best practice should be to use redirects. If you are using a representation URL you need to be clear it's not an identifier

jtandy: trying to summarise - you shouldn't be obliged to separate identifier and document, unless you see a good reason to do so

roba: a good reason to do so is to make it clear to users

jtandy: will park the discussion on Spatial Thing and Feature

Bart's demonstration of linking to WFS

BartvanLeeuwen: we're working for emergency services in cross-border or cross-discipline contexts
... there is more and more spatial data being shared between these partners in ad hoc ways
... For example, water boards collaborating with fire departments on flood evacuation plans
... The water board is opening up its SDI for the fire department
... For example the fire department comes across information about a critical section of a dike (i.e. high risk of a flood)
... misinterpretation between the two organisations of what was meant by 'critical'. Water board had a different idea to the fire department
... [Bart shows a GIS WFS system with attributes of objects on the map]
... so we suggest having a rdf:seeAlso attribute on all WFS systems, to link to a place to store more information
... Fire department is happy with an extra column in their system, but don't want to worry about supporting all kinds of formats
... following the seeAlso link goes to a Linked Data page about the thing, which in turn can link to definitions of concepts and other terminology
... so this is a simple and generic way of linking a WFS to a Linked Data representation of the objects
... We use standard linked data principles for dereferencing the URIs to get data
... Example showing a map of an incident, with icons to represent different situations, (eg a flaming icon to indicate a fire)
... this approach allows icons to be connected to definitions of what they mean
... and makes it possible to swap in different sets of icons for the same meaning, to make it familiar to someone from a different organisation
... From the opposite perspective, there is currently no standard way to link from the Linked Data representation to the feature on the map

ClemensPortele: there could be just a WFS request that returns the feature

BartvanLeeuwen: Jeremy and I have discussed this as a possible best practice

jtandy: so in essence, you are supplementing an existing SDI by putting one column in the database that links to a Linked Data representation, where all the semantic integration can take place - but you can still display it on a map
... beautiful in its simplicity
... (1) (maybe controversial) web mapping is explicitly out of scope - is this web mapping?

consensus: no this isn't web mapping, it's about linkability

jtandy: (2) I'm minded of discussions back in Amersfoort, where billroberts mentioned some hybrid approaches using triple stores alongside other things
... Bart's work seems a similar kind of thing

<roba> re embedding a link, of course the issue is whether the uri should be for a specific information resource or for an id which should dereference :-) There's your use case to consider

<Zakim> danbri, you wanted to say yay

jtandy: this seems to fit under the heading of data access - different ways of getting to the info

danbri: many examples that we were talking about earlier were very sparse, so not much benefit for the effort. This seems much more obviously beneficial as you can link together lots of things all at once

frans: can understand the perspective of the water boards on not wanting to do lots of work on detailed definition. But there is software that makes setting up a WFS pretty easy. If people act on our BPs then maybe publishing the supporting data will be easy in future too

Linda: thinking about how to fit this into the document. Is this a new BP, or a possible approach to implementing an existing BP?
... could maybe fit in BP11 about convenience APIs?

eparsons: this is more about the linkability best practice

roba: although I couldn't see the demo, I think I got the idea: this is a general use case of embedding a link to information about an object in another context
... so what kind of link do you embed in your data? a link to an identifier or another resource?
... probably need a standard practice here so that people know what to expect. It should probably be the identifier
... in that case the identifier can then link to various representations. Otherwise the implementer has to make a choice of which kind of representation to link to

phila: points out that in Bart's example, there is both information about the thing and information about the document about the thing. So this example makes the distinction between thing and representation

ClemensPortele: this example is mainly about easy data access. In QGIS you just have a string about the attribute. In the LD version, you can link off to definitions of the terminology

<roba> do you want t force all WFS to use exactly the same set of choices as to how to link to different resources and additional information - or make that the URI dereferencing practice?

ClemensPortele: it doesn't naturally fit in one of the existing best practices
... not sure if it's 'best' or 'common' or 'emerging'

<roba> best does not imply common, but if common works its probably "best". Where "common" is missing or doesnt meet identified needs best is closer to "good"

billroberts: I think it probably fits into our existing best practices on linkability and on making links

ClemensPortele: it's important to make it self-descriptive

Linda: maybe there is a DWBP we could link to

phila: point of process. Is there anything proprietary in Bart's work?

BartvanLeeuwen: no

<roba> its obviously about linkability - and if the practice link is to something via a URI that dereferences to a document that provides metadata, then it meets several BP cases

BartvanLeeuwen: would like documentation of which attribute to use for this, to try to make it more standardised

jtandy: different applications might require different data models
... so not sure we should specify always rdf:seeAlso or whatever

<BernadetteLoscio> I think is this one: https://www.w3.org/TR/dwbp/#ChooseRightFormalizationLevel

eparsons: this is good because you don't need to do anything difficult but has many benefits

<ClemensPortele> scribe: ClemensPortele

<scribe> scribenick: ClemensPortele

jtandy: next topics: General BP issues, Narrative, Plan for next draft

Are we meeting the needs of practitioners- if not, how can we improve?

jtandy: not writing BPs for managers, but for those doing the work
... are we meeting the needs?

frans: No. Related to BP on geometry, etc. Many options to choose from, but no real guidance how to do things

jtandy: agrees, we don't say how to make the choice
... Unlikely there is a single choice that fits everywhere. Example: GeoJSON.
... Struggles how to introduce the questions to ask yourself in the BP text.

frans: Can we also identify the characteristics a good format has?

jtandy: Probably difficult, depends on the perspective and use case. Support for one or multiple CRS is an example.

eparsons: We may be meeting the needs of the wrong partitioners, ie. the GIS community, less the "Web community"
... distinguish implementation recommendations / options based on the specific needs
... what meets the 99% of the cases, let's make that the default

Linda: are Web developers still in the audience, not so clear from the current text

(yes they are)

ByronCinNZ: A couple of things that may be missing:
... wider meaning of spatial beyond geospatial (but not really addressed in the text)
... clarify gaps that are relevant for bridging between SDI and Web developer community, e.g. spatial accuracy depending on the CRS/projection

jtandy: I.e., provide more help on how to pick the right datum/projection?

ByronCinNZ: Yes

jtandy: Any similar topics?

eparsons: Publish a raster or vector data?

billroberts: responds to frans "what is a good format" question: what will likely be used. So probably providing multiple options, e.g. GeoJSON for Leaflet and Shapefile for their GIS
... publish once, use many times

frans: happy to read in the current BP to focus on the use of the data and keep the users in mind
... points to limited choice of data types, which is currently missing for geometry
... we should work towards a single way of expressing geometry
... Also, current text is too much about geospatial data, less useful for use cases like architecture / BIM etc.

<Zakim> phila, you wanted to pick up on non-geo spatial

phila: content depends on contributors. Asks Chris from the BIM domain ...

Chis(?): Welcomes guidance. CRS guidance relevant and different CRSs will be used (e.g. inside the building). There are open questions how to do this best.

phila: Probably GeoFencing group did not consider the case where the CRS changes between two different polygons.

BartvanLeeuwen: Have we outreached to the "Web developer" community and asked them, if it is useful what we are doing?

phila: Trying to reach as many people and communities as possible

eparsons: Yes, what we do depends on the people who turn up

<Zakim> phila, you wanted to talk about this evening http://www.meetup.com/GeeksIn-Lisbon/events/233972259/

dmckenzie: We need to identify and contact the communities where we want feedback. Can use OGC communications channels.

<phila> Dev Meetup this evening

phila: that might have been an opportunity to pitch our work and get feedback

dmckenzie: many of these will be very regional, so hard to cover this broadly

billroberts: the extra day at Amersfoort may be a good example to follow

dmckenzie: OGC University DWG may be a channel for outreach
... or other DWGs that link to larger communities

<eparsons> coffee break until 14:50

<eparsons> coffee break until 15:50 sorry

"How do we kick the RDF habit?"

jtandy: you can use Linked Data in many representations, not just using RDF

frans: since SDWBP is an extension of DWBP, how is DWBP?

<ByronCinNZ> audio please. Sounds like an interesting conversation

jtandy: not heavy, but many of the examples use RDF

kerry: use of link type registry is one example that can help as it is general

jtandy: yes, publish semantics in the registry of IANA
... temporal relationships there is a proposal discussed with Simon Cox
... spatial relationships - there has been no feedback on which of the options to use
... on topology, direction, distance

<kerry> +1 in principle

(general agreement)

<AndreaPerego> IANA Link Relations: http://www.iana.org/assignments/link-relations/

Linda: but we need to agree on the list

AndreaPerego: have checked, if anything is there?

jtandy: Yes, nothing there

AndreaPerego: May introduce overhead on the publisher side. But has advantage that it can also be used directly in HTML

jtandy: Whatever we do, there will be some burden on the publisher, currently it simply is just no option that a publisher could use

AndreaPerego: maybe the profile link relation could be an option

kerry: it is important to capture the more informal spatial relationships that are used on the social level

<AndreaPerego> Definition of the "profile" link relation (from IANA registry): "Identifying that a resource representation conforms to a certain profile, without affecting the non-profile semantics of the resource representation."

kerry: ie the topological ones are not the most important ones
... focus on those that are used in common language

frans: why do we want to "kick the RDF habit"?

<ByronCinNZ> audio please

jtandy: if we focus on RDF people would quickly conclude the document does not apply to them

Linda: we have a link to the Linked Data BP this document becomes very RDF centric

<roba> using RDF is a practice - perhaps best for some things but not the only option.

jtandy: two schools of people, a) Linked Data must use RDF and b) takes a more relaxed position. Like the BP document...
... Need to use examples that are based on other approaches, GML, GeoJSON, maybe OData, etc

<Zakim> AndreaPerego, you wanted to comment on Fransis's point

AndreaPerego: Just to say that link relations are already used in HTML documents, e.g., to link to stylesheets. So, this makes it easier to use them to express also other relationships.

BartvanLeeuwen: Mention of RDF is a religious thing. People reject something just based on the reference to RDF

BernadetteLoscio: DWBP had similar discussion. Introduction has discussion of the relationship and avoid specific focus. But many examples are in ttl.

<Zakim> danbri, you wanted to discuss RDF

danbri: Have used RDF in other groups, but without making a big fuss about it

<jtandy> BP doc tries to present no bias to RDF here: http://w3c.github.io/sdw/bp/#linked-data

frans: having other examples is a good idea and the Linked Data text should state that it is not abut RDF

jtandy: Chapter 7 already does this, see link above

billroberts: you want web identifiers and you want linking, then you are nearly at RDF

<eparsons> ClemensPortele : RDF point was mine - current draft better

eparsons: Both the GIS and Web developer communities consider RDF a "nasty beast". So not highlighting RDF will help communicating the BP

jtandy: general consensus and going in the right direction
... how can we address kerrys point about the spatial relations. Can someone propose a list of spatial relationships?

phila: can we just register the ones from GeoSPARQL?

jtandy: Which of the three sets?
... and these are only the topological ones

eparsons: The directional and distance related ones are more of a challenge

kerry: Some of them are context dependent (near/far)

<Zakim> ericP, you wanted to ask about wikipedia infoboxes

ericP: could the wikipedia boxes provide any insight?

(possibly)

jtandy: is there a link to more information?

<kerry> https://en.wikipedia.org/wiki/Category:Geography_infobox_templates

<Zakim> phila, you wanted to talk about IANA Links don't need to be in a W3C standard, and to ask DanBri whether he can help

phila: topological ones could easily be added by contacting IANA / Mark Nottingham to add them
... for the others, is there something that we can point to?

danbri: we could also add them to schema.org

phila: how widely implemented are the relationships?

eparsons: typically widely implemented by GIS, so we would need to analyse what has been implemented in tools

<Zakim> billroberts, you wanted to ask about progress on relating things to geometry

<ericP> +1 to dim[B(a)∩I(b)]=1&<arg(x∨x_) ˚͜˚

jtandy: and how do we identify the directional / distance-related ones? any sources to use as a basis?

billroberts: related to the work on the spatial ontology
... can schema.org help?

danbri: there are existing properties that relate objects to geometries

PROPOSED: submit topological GeoSPARQL Simple Feature relations to the IANA link relation registry.

frans: there could a difference between the spatial relation of spatial things or their geometries

eparsons: the topological ones depend on the existence of geometries
... ... the topological ones are always computable from the geometries

ericP: and how about the more fuzzy relationships

<Zakim> phila, you wanted to talk about Young's Calculus

DanhLePhuoc: (sorry, I missed that)

phila: if we have the list of well-defined relationships for topo ones, should we do this for the temporal ones (Allan's calculus), too?

<DanhLePhuoc> there is some relationship can be calculate without geometric information, for instance, located in, part of, can be computed via transitive reasoning

jtandy: I can make topologial assertions without geometry.

<danbri> phila, see "We don't nitpic about whether they're alive, dead, real, or imaginary. " in http://xmlns.com/foaf/spec/#term_Person

eparsons: but you cannot prove them

kerry: the informal ones are more valuable to the formal ones

<eparsons> +1 tp both

<Zakim> danbri, you wanted to mention 'equals'

danbri: only one seems only useful in a mathematical sense (equal), the others also make sense in a colloquial sense

<Zakim> kerry, you wanted to mention https://jena.apache.org/documentation/query/spatial-query.html

jtandy: It would be a well-defined topic to make a proposal for the link relations. Any volunteers?

phila: where to put, in schema.org, W3C space? Should it also go to the BP, too?
... IANA wants to reference something stable

<Zakim> ericP, you wanted to propose email

ericP: simplest could be an email to the mailing list

kerry: this might be a starting point: https://jena.apache.org/documentation/query/spatial-query.html

<Linda> And schema.org has https://schema.org/containedInPlace I saw

<RaulGarciaCastro> scribe:RaulGarciaCastro

jtandy: we want to include: computable relationships and assertive relations (not necessarily based on computations)
... … who can take the lead for doing that?

eparsons: what has to be done?

jtandy: name + description

<phila> An excellent example of a namespace document

eparsons: I take the lead

<ericP> An adequate example of a namespace document

jtandy: there is no best practice for these relationships; there is a gap there

<ericP> (though it does introduce some convention for properties of a class)

jtandy: … could this be part of the namespaces work?

(yes)

jtandy: how to use spatial relationships for uncertain boundaries? There is a common practice to do it

<eparsons> action eparsons to work with chairs to define spatial relations namespace document

<trackbot> Created ACTION-198 - Work with chairs to define spatial relations namespace document [on Ed Parsons - due 2016-09-26].

kerry: we can handle it talking about fuzzy relationships
... … and I don’t even need to knwo the geometry

eparsons: sometimes there are things with no geometry associated

roba: relationships depend on the use case; we need a mechanism to specify what you need in your context

frans: if we relax the relationships to things without geometry, anyone can make a statement about anything

<Zakim> ericP, you wanted to ask if time management mechanisms can be used here

ericP: you should expect people acting in good faith (a trust issue)

jtandy: some expert should help me with the examples of spatial relationships
... bill, what are your thoughts about producing statistical data?

AndreaPerego: When are we talking about SpatialThing vs Feature?

eparsons: let’s plan now with everyone here

<Zakim> phila, you wanted to ask BernadetteLoscio and newton their thoughts on the usefulness of the running example

phila: Is narrative important?

BernadetteLoscio: The running example was useful, even if in some cases it was difficult to come up with it

jtandy: We were thinking on a flooding example, but it is complex
... … I don’t expect the best practices to be used alone, but with other documents

eparsons: Maybe we could reduce the scope in the narrative?

jtandy: Some answers that the narrative is supposed to answer are already answered in the document

frans: How about using the narrative in the examples to give coherence? Right now it is separated

eparsons: Maybe we can prioritize the best practices
... … trying to include everything makes things complex

billroberts: have been trying to find population statistics and examples, and this raised a number of questions that can be performed (e.g., is the population data in machine-readable form?)
... … this can give hints to data publishers

ClemensPortele: If you remove the narrative and put it into the examples it may not be so convincing

jtandy: how do we plan net steps? (will think on the narrative for tomorrow)

Linda: how far is the current document for the next working draft?

<Zakim> phila, you wanted to be annoying

<kerry> +1 it has moved a lot from previous version

<eparsons> +1

phila: The document is already very good; please publish it as soon as possible
... … feel free to take things out
... … right now it is more than expected

eparsons: publishing it is the way of getting more people involved

phila: get what you got in a published document (even with open issues) in a week or two

jtandy: Pending things: update the glossary with missing definitions (anyone?), bibliography, open issues, changelog…

phila: I will help with the document (formatting, language, etc.)

<danbri> http://pending.webschemas.org/GeospatialGeometry (based on https://github.com/schemaorg/schemaorg/blob/sdo-callisto/data/ext/pending/issue-1375.rdfa (based on https://en.wikipedia.org/wiki/DE-9IM )). Various 'deliberate mistakes' included to check if anyone reads it.

AndreaPerego: Do we need the notion of a spatial thing? Not in every case we need to differentiate between real thing, geometry, etc.

<roba> josh lieberman was working on an abstract spatial ontology - i think we need this to be a lightweight core

<roba> ...updating geosparql may end up with something too complex ?

<Zakim> danbri, you wanted to re-iterate SpatialThing was from a random chat

jtandy: In the document we already state that a spatial thing can be different things

danbri: the origin came due to trying to adopt CYC

AndreaPerego: And people have used it since then

danbri: We can still change it

jtandy: The concept of spatial thing for representing things with extent is good for us
... the GeoSPARQL ontology is being refactored
... … anyway, review the document to see if the current use of the term makes you happy

Linda: we have reviewed the document

jtandy: Ensure that the glossary is consistent with the wiki (anyone?)
... … it is just a compilation thing, no need to write new content

<BernadetteLoscio> https://www.w3.org/TR/dwbp/#requirements

<danbri> re basic geo ns, it came from a https://www.w3.org/wiki/ScheduledTopicChat meeting. https://www.w3.org/wiki/GeoInfo which has 404 cyc reference -> http://www.cyc.com/cycdoc/vocab/geography-vocab.html - earlier version, https://web.archive.org/web/20070203153714/http://cyc.com/cycdoc/vocab/geography-vocab.html

<phila> BP cross ref

<danbri> so yes, SpatialThing came via Cyc, e.g. #$SpatialThing-Localized

<danbri> http://sw.opencyc.org/concept/Mx4rvVjpUZwpEbGdrcN5Y29ycA

newton: I made a script to build the cross-reference table for our best practices document; I can help with this document

<eparsons> Action billrobe_ to check Glossary for completeness

<trackbot> Error finding 'billrobe_'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.

<Zakim> danbri, you wanted to confirm SpatialThing was indeed Cyc-inspired, see http://sw.opencyc.org/concept/Mx4rvVjpUZwpEbGdrcN5Y29ycA (also to report

danbri: went through the wikipedia infoboxes for relationships properties and there are proposals in schema.org; but nothing has been assessed by experts

jtandy: Regarding bibliography, proper references in ReSpec must be found (in yellow)

phila: I can manage that

<phila> ACTION: phila to help improve the bibliography for the BP doc [recorded in http://www.w3.org/2016/09/19-sdw-minutes.html#action01]

<trackbot> Created ACTION-199 - Help improve the bibliography for the bp doc [on Phil Archer - due 2016-09-26].

<Zakim> kerry, you wanted to talk about tomorrow agenda before we leave

phila: I can help in placing the icons for the benefits

jtandy: we will try to have a stable release in two weeks from Wednesday (15th October) so it can be published the following week
... Thanks for all the comments

<danbri> @phila, to answer your http://schema.org/ process question - my actions fall under project webmaster role documented in http://schema.org/docs/howwework.html#webmaster 

<Zakim> AndreaPerego, you wanted to ask about the agenda for the SDW workshop @ INSPIRE 2016 (Sep, 30th) http://inspire.ec.europa.eu/events/conferences/inspire_2016/page/wsl

AndreaPerego: do we want feedback from INSPIRE in the best practices?

jtandy: tell them about the new future draft so they can give feedback

AndreaPerego: We must highlight what we want feedback on
... … the workshop is next week on Friday

jtandy: We can talk about it

eparsons: I can present if you give me the content

Agenda for tomorrow

kerry: (reviews agenda)

phila: There is the AC meeting tomorrow at 15:00
... … it may affect the meeting

meeting closed