Spatial Data on the Web Working Group TPAC F2F Day 1

<trackbot> Date: 25 October 2015

<eparsons> Meeting: SDW TPAC Day 1

<eparsons> Still waiting for a few people...

<eparsons> Still a few connection porblems...

<eparsons> scribe: ahaller2

<Kerry> Presentt+ kerry

<eparsons> jtandy In describing context of BP document "Best practice not best theory"

<phila_> The Charter

<eparsons> jtandy - "spatial data still mostly in SDI silos"

<phila> eparsons: If we can provide the mechanisms, it will make it much easier for people to publish spatial data

<phila> ... we all feel that there's more that can be done to make it easier for publishers

<phila> scribe: ahaller2

<phila> scribeNick: ahaller2

jtandy: assumption is that the Web is the data sharing platform
... how can machine detect facts, especially if places are expressed in different levels of granularity
... ABS, for example, is publishing data within spatial regions
... challenge is, to combine data that may refer to the same place, or not

<phila> Europe uses NUTS codes to refer to regions for statistical reasons. https://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics

jtandy: identify tools and methods for publishing geospatial data

phila: geoJSON for example, is a language that is not standardised
... Time Ontology is not a recommendation

jtandy: places change over time, and therefore the temporal aspect is important to be captured

eparsons: we only formalise a standard where necessary
... benefit to point to best practises rather than inventing a long list of recommendation

phila: reminding that this group runs in collaboration with the OGC

jtandy: OGC is about 25 years old
... based around a consensus process
... working drafts in this group are published as drafts in OGC

<phila> The WG's Use Cases doc

eparsons: is doing patent call

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

phila: OGC requires to say at the beginning of every meeting to ask if there are patent claims

no objections from the group

<eparsons> Still connectivity issues for windows users - noted :-)

jtandy: is presenting the use cases document
... linking data is one of the key aspects we will be working on
... second objective is semantics, just enough semantics
... to describe, for example, other metadata in GeoJSON that is not geometries

<eparsons> The seven themes Liking data, Publishing Data, access via API's, Discovery, ID's, spatio-temporal , Sensors

jtandy: another aspect is to describe places, for example, in the UK, if you say, we meet 'on the green' for tea and cakes on a sunday afternoon, we need to know what 'the green' is
... enabling discovery is another important aspect of this WG

<eparsons> OCC standards require expertise in Geospatial

jtandy: assignment of identifiers
... for example, features, like a post box, or railway station, but in the geospatial world, the document is meant, whereas in the LOD there is a separate identifier for both

<eparsons> Things vs Features different approaches SDI and Web

jtandy: expressing temporal and spatial information
... we want to be able to give you a best practise to when to use what vocabulary
... there is also the Time Ontology which needs updates, first published in 2006, but it can only to Gregorian calendar
... we need another temporal reference system
... there is no way of describing intervals as first class citizen

<eparsons> BartvanLeeuwen questions around vague descriptions of time

jtandy: another important aspect in this group is to talk about sensors
... there is the existing SSN ontology
... there is also an observation and measurement ontology
... we want to formalise how this metadata for sensors is best published
... the last aspect is, dealing with large datasets

<phila> BP doc editors' draft

jtandy: we need to subscribe as a group to the 'Architecture of the Web' principles
... best practises that do not fit with the AOW are not acceptable

<jtandy> http://www.w3.org/TR/webarch/

eparsons: OGC may not subscribe to these AOW principles, but this group is on the forefront to potentially initiate this change

jtandy: OGC recognises that 'pointy APIs' as they call it is really useful on the Web, but some of their recommendations are too complex and don't work well implemented in APIs

edparsons: OGC is developing standards for the spatial community, but they recognise that other people on the Web would use their geospatial standards

bart: maybe we can say this the other way round too, maybe the Linked Data approach is not used by the Web community either

jtandy: we did agree in this group that the Linking of data in the geospatial domain is really important

eparsons: we love the 5 stars, but we don't need always to aim for that

sangchul: we use URIs to recognise physical objects

<phila> BP draft, now with Linda included as an editor

sangchul: we develop www.insightar.org
... in an article that we published recently in a journal, we propose a different approach to identifying things other than URIs

eparsons: it is very valuable that we get input from the community to know what other approaches to recognise things are in the geospatial community

tahar: do you intend to extend SSN for other uses cases?

kerry: yes, we intend to extend SSN

<jtandy> Semantic sensor network ontology: http://www.w3.org/2005/Incubator/ssn/ssnx/ssn

kerry: there is for example, actuations that is not covered by SSN and which may not be enough driver in this group, but the WoT working group might provide us some input here

jtandy: currently there is a disjoint between how geospatial community formalise observations and measurements and how the semantics community is doing it

tahar: SSN does not have a big enough footprint yet

kerry: there are other things bubbling up that are related to SSN, for example, the sensor things api in the OGC

tahar: I have followed the academic community, but the developers are not yet picking up the SSN on the Web

<eparsons> ahaller2 Group will make SSN more modular ? More accessible

bart: most providers of sensor data want to keep their data close, as it is there unique selling proposition
... they are not interested in publishing data freely

eparsons: the market will decide if a standardised approach will succeed

jtandy: one of the themes we need to focus on is to provide data through APIs

<Zakim> phila__, you wanted to highlight http://www.w3.org/TR/generic-sensor/

eparsons: the OGC is challenged by defining what an API is

tahar: footprint SSN could have for sensors, we need SSN to be less data intensive

kerry: yes, that is one of the aims in this WG

jtandy: the ontological commitment to the dolce upper level ontology is known to be an issue for the uptake

eparsons: we aim to do a spatial rosette to the spatial data 5 stars

jtandy: Another aim of this group is to align with the Data on the Web Best Practises WG

<jtandy> http://w3c.github.io/dwbp/bp.html

<jtandy> (data on the web best practices)

phila: the DWBP WG has some very basic recommendations, such as 'you should provide metadata', but there are more techie ones later

jtandy: since we are based on this work, we don't have to write down that we need metadata, because that is assumed by this DoW WG document

s/DOW/DWBP

jtandy: Hadley Beeman is the chair of the DWBP WG and she will be joining us

<eparsons> Kerry We should note where we interest with other groups eg. Data on the Web, WoT

kerry: we need to take notes today for things that we need to sync with these groups, i.e. DWBP

<jtandy> linking data theme: https://www.w3.org/2015/spatial/wiki/Linking_Data

eparsons: we are not doing SSN in the next two days, focus on the BP document

jtandy: however, we need to hear from people how they intend to use the SSN ontology, because that will inform the BP document too
... planning the rest of the day and the distribution of the themes for the remainder of today and tomorrow

Linking Data

<phila> scribe: phila

<scribe> scribeNick: phila

eparsons: Before we start writing, we thought we'd talk a bit about GitHub

jtandy: Shows the GH repo http://github.com/w3c/sdw/
... talks about Pull Requests
... Request is that everyone contributes, but that only editors merge Pull Requests

Jeremy Demonstrates GH process

-> http://www.w3.org/respec/ ReSpec

jtandy: Shows importance of making a summary comment when creating a PR

Please don't make changes directly in gh-pages

jtandy: Asks that you push to a branch and then create a pull request for the editors to merge your changes into the GH-Pages branch
... Recommends using rebase cf. merge after fetching

eparsons: Is keen to get on
... Asks jtandy to either create a wiki page about how the editors want to use Git or send a message to the list

<jtandy> https://www.w3.org/2015/spatial/wiki/How_to_work_with_GitHub

Recording the fact that Jeremy completed his action to put info on the wiki before the scribe had a chance to put it in trackbot

eparsons: Now we areally are going to talk about linking

-> https://www.w3.org/2015/spatial/wiki/Linking_Data Linking Data wiki page

jtandy: Goes through the summary list
... I think that linking between things at the dataset level is largely covered by DWBP. Its' about links between items within datasets, crawlable etc.

eparsons: It's important to socialise this. As LD, Geo and Web community not all on the same page
... The thing/the representation... we think in terms of the world in terms of points, lines and areas and we're happy to give those things IDs
... but that's not always what we're talking about, esp if features don't have a geometry 'the Mid West', the east end of London etc/
... or there may be many geometries

Linda: But the whole Thing/feature discussion goes here or in the identification theme?

jtandy: I think it goes in the ID theme but we still need to talk about linking
... SDIs don't talk about the real thing, just the description which is an information record
... whereas in the LD world, we want to identify the real world thing
... We have agreed that the LD approach is what we want to follow, which doesn't necessarily mean RDF but that's probably the easiest way
... Need to think about attributes. Lighthouses have things like a height, spatial coordinates etc.

eparsons: I think we just need to write a narrative around the different world views

jtandy: We see another feature that talks about the same thing. May see the lighthouse as a navigational aid
... You can merge the different features that talk about the same thing (or not merge)
... Imagine a dataset of lighthouses in UK, we'd give the dataset an id, and then inside the dataset there woujld be local identifiers

<eparsons> Not merge is important

jtandy: Local names are not typically URIs. We know we want to use URIs as identifiers. So we might take the dataset URI - which identifies a silo
... think of a different dataset, this one about shiprecks near lighthouses. But problem is mapping the local IDs, we want to be able to express the linkages within the dataset

eparsons: That introduces the more fundamental issue - we need the granularity to be able to link to an individual lighthouse

timbl: So the aim is to produce a shim layer to enable things in the dataset to be exposed as LD?

jtandy: I see that as being important, yes.

eparsons: A shim might be the solution, but we want to encourage/enable people who are using W*S services to create that set of URIs
... these are things you can add to your data to make it more linkable
... We don't want to put any overhead on publishers that we don't need to.

Kerry: I'd expect to go a little further in the ID section and talk about using URIs within the dataset

jtandy: Talks about use of authoritative sets of URIs, if you can find them
... and a third party might create a saemAs set

<ahaller2> s/saemas/sameAs

LarsG: It's out of scope to discuss who has the authority to create those URIs

Unanimous: yes

timbl: Work will be done by people motivated to do it.
... And the BPs should encourage/facilitate that

eparsons: It might be helpful for us to help to identify those authoritative sets
... We could offer examples where it is appropriate to mint authoritative URIs

BartvanLeeuwen: I wonder if we want to go one step further and talk about features and making the properties more LD-like
... How do I know what height means on a feature?

jtandy: We need to ensure that when people are publishing data that they have explicit semantics
... In the LD world, the predicate has a URI that you can look up. In the SDI world, it will be published as GML and that will say that it's written according to a XSD over there - and you don't always find that

BartvanLeeuwen: We have a case in emergency response when working cross broder

jtandy: Talks about ht and ho as possible EN and DE abbreviations for height which would cause problems

kerry: we are committed to making our vocabs multilingual as far as we can

eparsons: Gives example of heights above sea level and floors in a building - different ways of describing the same thing

BartvanLeeuwen: German and Dutch notions of ambulance are different since German ones have two types of crew depending on the expected severity of the incident
... no equivalent in NL

jtandy: Anyone could crerate a taxonomy of ambulances and it's up to the community to decide which one to use

BartvanLeeuwen: if you're going to publish this data then people should be able to look up what it means

LarsG: I'm less concerned with false negatives. But false positives think that two things are the same - e.g. creator of the feature or the real thing

jtandy: I recognise the problem you're identifying

<ahaller2> phila: people called the same thing different names. PROV has some good solutions for that. For example, for the lighthouse example, Navigator calls the lighthouse something, geographer another name. PROV can be used for that.

jtandy: Because the GIS community has this issue of descriptions and real world things, we could refer to the Data in URLs work that JeniT did

-> http://www.w3.org/TR/urls-in-data/ Data in URLs

jtandy: The lighthouse is the thing. Landing page would be the record

eparsons: The landing page is something I can crawl, a record in a database might not be that

jtandy: This is an FPWD, it says that a landing page is similar to a record.
... it makes some proposals around properties and shorthand properties

timbl: From experience of playing with VCard... A card is a social entity, either person or organisation
... you get this data that says this is a person
... it represents a business card and you can get hooked up on this. It turns out that talking about the card isn't usually useful
... in fact just treat it as being about the person
... Life's too short to get too hung up. Punning can be good.

jtandy: I saw something about this in some work from CSIRO. What was accessible on the WEB via WFS, implied that certain things existed and then used those IDs about the real world as the basis for reconcilliation.

ahaller2: In DCAT there is a distinction between a landing page and a document

jtandy: I just put the data in URLs work up as an example of where someone has done similar work

ahaller2: DCAT has different URIs for dataset and landing page, CKAN does it differently

jtandy: We don't want to go down the rat hole

eparsons: In the BP doc, we'll need to recognise the problem and try and give some guidance without necessarily definitively solving it

jtandy: We could perhaps point to the CSIRO work as an example of how to pull out/infer IDs for real world objects

Linda: We added some data to some existing data about trees without getting too hung up on the details
... So we're saying that features are info records and for practical purposes you can treat it as the thing.

Kerry: That's too strong

timbl: I was saying you shoujldn't get too philosophical about it.
... The URI is generally for the thing and you're probably not so interested in the document

jtandy: If I have an ID in the dataset for 'Eddystone' then maybe I can infer an identifier within a dataset of Lighthouses that 'Eddystone' is something like lighthouses.com/Eddystone and that's the real thing

Linda: So how do you know how to reconcile across datasets?

jtandy: offers '303' and 'Eddystone' as internal IDs in diff datasets for the same thing

Linda: And if you know that they're the same, how do you make that assertion?

jtandy: You need sometehing like a sameAs statement

Linda: We have 2 datasets in NL about buildings, really a 1-1 set. One dataset has all the IDs of the other dataset in them.

jtandy: If you choose to subscribe to the assertions that that two things are the same.

eparsons: The key thing we need to do is to provide advice to publishers on how to make the data more accessible, more usefeul
... we just need to come up with simple guidance. It's about URIs for your things, but I don't think we should worry too much about the mapping from one person's data to another.

jtandy: reconciling is a hard job.

eparsons: It's a really hard job.

jtandy: There will be a debate about what people mostly want to ask questions about.
... Channelling Bill Roberts, people want to ask questions about real stuff, not the records about them.

eparsons: You can clearly version things as tech improves and techniques improve.

jtandy: Hydrologists define catchments. Historically, catchment has been defined as the basis of an elevation model which got updated and, in the process (computer-wise) created a new piece of the world.
... I think we're agreeing that the entity that people are most interested in learning bout is the real world thing.

Kerry: Catchments don't have a real world existence. It's an abstract idea and they change anyway...

LarsG: A real world object is a real world object in the domain of discourse. So if catchments are in the domain of discourse, they are real

Linda: So can we use the hydrology example as an example of a bad example?

jtandy: I don't think we can...

Linda: No the way they did it with the historial aspect

eparsons: Ah yes, but maybe without calling it a bad practice, mor an exmaple of someeting to avoid.

jtandy: So we have 2 examples of BP we could apply
... One on UK consistuency boundaries and the otehr is the Australian catchment data
... In CSV we have the crime data which was difficult as the boundaries of crime areas changed from one year to the next.

eparsons: You need to say 'you need to think about this'

jtandy: Point 3 on Linking data is Spatial datasets are different in that they will (usually) have an "extra level of structure and granularity that is reflected in the data" e.g. the use of geometry and spatial relationships
... Is there something special about Geo that doesn't apply to non-geo data

eparsons: I thought this was about recognising that geo data can be heirarchical - a village is part of a county is part of a country
... there's a heirarchical relationship that isn't geospatial

jtandy: There's a geographical, topological anad social heirarchy. Does that make our data special or is it all DWBP?

eparsons: I don't want to fall down the trap of always using the topological relationships

jtandy: Places without boundaries, or with indistinct boundaries
... are a problem. We have social boundaries, like 'London'
... I might want to say that my working place is 'in London' when it is legally somewhere else.

Kerry: I think that's more of an identifier question.

eparsons: I want to be able to link something I can draw a boundary around to something I can't (or vice versa)

ahaller2: Questions the specialness of spatial data

Kerry: I think we do need to define the relationships.

<ahaller2> phila: talking about charter: relationships that are very well known in this community are not registered in the IANA registry. Best practises document is only a note and not in the registry. But we are allowed as a group to develop further recommendations that we can put in the registry.

<ahaller2> ... link relationships are important and we may need to define a new recommendation, but it may be enough to have it in the Best practise document

-> http://www.iana.org/assignments/link-relations/link-relations.xhtml IANA Link relations

jtandy: We have had agreement in our discussions around point 5 - Links are first-class citizens - it is 'connectedness' that makes for "Data on the Web"; allowing one to discover new information by traversing those links

eparsons: And I think that's where the biggest change will come in the GIS world

jtandy: We want data to be traversible via links
... We want our datasets to infer a bunch of hyperlinks that can be link to other people's stuff.

Linda: So it's useful to have hyperlinks to things like Goenames, wikipedia etc.

jtandy: It's not our job to curate those

eparsons: No, but it's our job to give examples of what you can link to
... In Open Street Map, every item has an ID that can be accessed via a URI
... That's not true with WFS and I think OGC needs to move in that direction

jtandy: We need to find a way to make it convenient to publish summaries of those linkages so that they can be discovered at the dataset level
... You can publish things that refer people to a service that does stuff to the data

<Zakim> phila, you wanted to talk about HAL

<Zakim> phila, you wanted to talk about HAL https://tools.ietf.org/html/draft-kelly-json-hal-07

<ahaller2> phila: talks about HAL, IETF draft, it is not RDF, but Linked Data

-> https://tools.ietf.org/html/draft-kelly-json-hal-07 JSON Hypertext Application Language

jtandy: Point 4 - Representations may be provided with varying degrees of authority and currency, for differing scales and purposes
... There should be info about who published the data so others can decide how authoritative it is.

eparsons: Talks about the many maps of Jersualem - none of them the same
... so you need to know who produced each one so you can choose the one you want to use.
... It's a common misunderstanding that maps are accurate and they agree.

=== LUNCH ===

<deiu> hadleybeeman, 202

<eparsons> === LUNCH END ===

<eparsons> kerry Web of things / SDW ad-hoc will take place on wednesday

<eparsons> Details TBA

eparsons: We want to recap the main points from this morning whuile it's fresh in our minds

-> http://www.w3.org/2015/10/25-sdw-minutes Minutes from this morning

<eparsons> scribe : eparsons

eparsons - recap of this mornings discussions to id main points for BP doc

Linda Linking between things should be data on the web deliverable

BartvanLeeuwen We should make sure there is practice not theory..

jtandy links between representations via social identification

phila relationships can come from SDW BP

phila OK to use FPWD to identify "stable" relationships

<phila> Key thing is that relations need to be 'reasonably stable' - the main spatial and temporal rels fit that description. Whether doc is a Note or rec doesn't matter.

jtandy Need to provide practice to map from feature identifiers to global id's of things

jtandy if a id exists somewhere you should use it in your dataset, if not mint one

<Zakim> phila, you wanted to talk about http://philarcher1.github.io/dwbp/bp.html#identifiersWithinDatasets

phila my link proposes approach from data on the web group to do this

phila e.g. how to mint URIs

jtandy "Same as" linking or ID issue but should be recorded

jtandy "assertions" should be recorded related to provenance

<phila> The 'profile' Link Relation Type

jtandy "how do we know what is at the end of the link"

LarsG This is what shape should do..

We need to deal with publishing semantic data tomorrow morning LarsG time constraint

jtandy we do not bless who has authority

<phila> Best Practices for Publishing Linked Data (includes info on publishing vocabularies)

phila above url has pointers as to how to select data sources "Gut instinct"

BartvanLeeuwen Mapping between semantics is application specific, publisher requirement is to make data mappable to allow this

jtandy Spatial Identify Reference Framework from CSIRO is reference for asseration based linking

<phila> The research paper on using PROV to distinguishg between world views is at http://link.springer.com/article/10.1186/s13326-015-0008-2/fulltext.html

<phila> Capturing domain knowledge from multiple sources: the rare bone disorders use case

jtandy publishing link to authoritative data that are related is needed

jtandy representations may change but thing does not e.g admin boundaries and catchment definitions (actually ID subject)

jtandy relationships can be geographical, topological or social need to do all

kerry should relationship vocabs be part of BP or created elsewhere

jtandy: BP should signpost useful sources of links, e.g Geonames

Kerry: Mailing list contains more details "stamp collecting"

<Zakim> BartvanLeeuwen, you wanted to discuss dinner after this topic

jtandy: to make data work on the web links between features need to be discoverable - linksets ?
... item level links difficult for data publisher, 3rd party mechanism should be possible

kerry: backlinks also ?

jtandy: UK gov publishes gazetteer, other air quality , tourism etc... back link is link back to gazetteer

phila: linksets a separate doc ?

jtandy: Missing true, a note around link sets might be needed

phila: Could be joint doc with data on the web

larsg: Why should I do this people might ask if no one can consume..

phila: linksets are used in life sciences e.g. openphacts

<phila> s/openphacts/http:\/\/openphacts.org/

phila: We need to prove BP is used, eg evidence of use by at least one org

<BartvanLeeuwen> scribeNick: BartvanLeeuwen

link publication format

eparsons: is this about linking the representation level

jtandy: it is about how write the links down, the choice of encoding
... how to encode links and how to use a api that support coneg

<phila> scribe: BartvanLeeuwen

<phila> scribeNick: BartvanLeeuwen

jtandy: the URL for accesing a data service endpoint is not the same as the dataset URI

<phila> jtandy: Tries to summarise previous discussion. I see 3 options for describing subsets...

<phila> eparsons: It's mostly about coverages, not feature sets

<phila> eparsons: Identifying coverages and subsets of coverages

<phila> .. So I think we can do this in the API section

<phila> ahaller2: SPIN solves this problem and a lot of people use SPIN

<phila> ahaller2: SPIN is a vocab for storing SPARQL queries

<phila> jtandy: Rather than using SPIN per se, we can use a provenance chain to say what query you used

<phila> scribe: phila

<scribe> scribeNick: phila

ben: Then the identifier would be the ID of the Prov entity

Time Out on that discussion

Things we want to agree/disagree on

jtandy: We find the e-mail discussions tend to offer RDF-centric solutions, but is that because of the self-selected group?

BartvanLeeuwen: In NL we have the Linked Data Platfom
... Someone came in and starting showing his use of JSON-LD claiming it wasn't RDF

eparsons: As long as people are providing some context etc. we shouldn't need to force people to use RDF

jtandy: We recognise that people will want to publish GML

eparsons: Well yes but we want people to think about how to make it linkable
... We need to offer advice on how to do that with technologies and principles that your data format must support.
... It's about making your data more accessible and linkable.

Kerry: which means we want to include stuff that may not yet exist?

eparsons: If we end up suggesting that people use things that don't exist, that's not good.
... If you want to continue to use GML then OK but you need to do XYZ

LarsG: Does that mean that you have to do things multiple times to met all the Best practices?

jtandy: Maybe we need to have a matrix showing all the BPs as column headings, formats as rows, showing which BPs can be applied using that format.

<ahaller2> +1 to jtandy's proposal for a matrix

Kerry: We need to be careful not to suggest we're being complete.

eparsons: We should shy away from saying that a tech is really good if we think it is.

jtandy: That matrix might help people make a choice of format.

DDahl: introduces herself and EMMA http://www.w3.org/TR/emma/
... EMMA 2.0 includes a location element
... so devices can location or time stamp data
... the attributes we includes are the ones you can get out of the geolocation API
... It might be interesting to think about what attributes we might add to our location element
... There are 2 attributes that we added to the location element that aren't in the Geolocation API. Address and description
... It occurred to me that things like whether the interaction was within a car
... Extra semantic info is totall unstructured so I came to see if there are ideas here.

eparsons: That sounds like potential use cases. We talked this morning about encoding relationships, including social ones that go beyond the usual 8 logical ones.

jtandy: Being able to make explicit statements is important to our use cases.
... If two polygons overlap, are they the same thing?
... Our vocabularies need to be rich covering geographical, topological temporal and social.

<eparsons> FYI URL for webex in 30 minutes will be https://mit.webex.com/mit/j.php?MTID=me0a211eec033a37d59a1670bf6d727d7

jtandy: You might want to say that an incident took place after the journey started and before it ended.

<jtandy> (and a journey is a topological construct with a beginning and end ... we might want to say that an event happened at some point on the 'edge' between the two well-defined nodes)

DDahl: It seems that the basic "I am here# message, but we don't have a way of capturing more social info like "I'm on my way to work.."

<jtandy> (we might not know exactly where on the 'edge' that the event happened - just somewhere during a journey)

DDahl: I was also thinking that a concept like 'near' it depends whether you're driving or walking, what near means.

jtandy: We think we'll have to specify which vocabulary to use to describe a location.

assignment of identifiers to ‘real-world things’ & information resources

jtandy: It's clear that people are using twitter has tags as location IDs

eparsons: There's no management of that, which is what I think it's about. It was developed from the bottom up.
... The key thing is that people can produce URIs on the fly

jtandy: In order for URIs to be useful, people need to be comfortable in creating them themselves

eparsons: (with guidance from us). There are good and bad ways of minting URIs
... There is no ICANN for place names

jtandy: if you've done a modicum of due diligence and not found one, OK, create your own.

Ben: Are those URIs are going to be dereferenceable?

jtandy: That is best practice
... What it resolves to is a bit of an open ended question

eparsons: That's partially answered by the discoverability aspects.
... Maybe we need something that says there should be something crawlable
... If we can point to a HTML page that is well structured and describes a thing that's always going to score more highly than something unusable.
... You could have a URI for every post code, or you could have a URI that returned info about that post code, place associated with it etc - that's going to score more highly.

jtandy: If you have a dataset and you want to make each item dereferenceable, you're not going to create 1600 URls probably

eparsons: So you need an API that returns a page
... gave an example of a Canadian city that tried a system that created a page for an area if you asked for it, within a short time. But what worked better was a page generated automatically on the fly
... That's what was crawled and used.
... URIs good, URLs better

Discussion of versioning, URI for latest version and immutable snapshots

scribe: Covered in DWBP

<ahaller2> +1 to covered in DWBP

<ahaller2> i can scribe

Nanimo?

Nanaimo

<eparsons> http://maps.nanaimo.ca/data/property/

Linda: Content is growing in the BP Doc at http://w3c.github.io/sdw/bp/ so there's more than the IRC log being captured

<eparsons> One again webex is at https://mit.webex.com/mit/j.php?MTID=me0a211eec033a37d59a1670bf6d727d7

<ahaller2> scribe ahaller2

<eparsons> ask here for password

<kerry> webex is open for business!

<ahaller2> scribe: ahaller2

scribenick;

<scribe> scribenick: ahaller2

<jtandy> scribenick: ahaller2

jtandy: next issue, non-unique naming

<kerry> webex is at https://mit.webex.com/mit/j.php?MTID=me0a211eec033a37d59a1670bf6d727d7

jtandy: sameAs is a very strong assertion, we need a lot more weaker assertions

LarsG: schema.org has a sameAs that can be used between documents and entities, it is much weaker than the OWL sameAs

kerry: we don't want the OWL one
... the logical theory in OWL does not say that two things are the same

eparsons: I like schema.org sameAs, because it talks about webpages only

jtandy: document that describes our lighthouse entity example could use the schema.org sameAs

ahaller2: we need to be careful not to ignore the best practise in Linked Data that uses OWL sameAs to assert the equivalence, even though it is bastadrised
... schema.org sameAs is a bit confusing, why not using a different name if we come up with a similar property in this group, and then say it is equivalent to the schema.org one

jtandy: schema.org, sameAs is really to express, i am a document (description) about a thing

eparsons: the audience of schema.org is web developers, content creators who create web pages

jtandy: OWL sameAs is not enough, we need to say that there are many mechanisms to reconcile identifiers
... spatial correlation is useful to determine equivalence, but not always
... if you publish sameAs relations, say who you are

LarsG: broader and narrower within a dataset imply broaderTransitive, narrowerTransitive, Mapping relations broaderMatch, narrowerMatch do not have these assertions

eparsons: are there best practises

ahaller2: skos mapping relations are used in the wild

jtandy: we don't want to make up stuff
... if we feel the lack of a best practise is impeding, then we can come up with a solution
... emerging best practise

eparsons: we need to be careful, things we just make up, are not best practises

kerry: we need a more social notion, samePlaceAs

eparsons: there is a whole new science area, placial science

jtandy: there are two places that are talked about in two communities that are actually the same place

eparsons: same spatial context
... this is a gap, so we don't have evidence, we may propose recommendations for this

jtandy: we, as a community of experts recommend a solution in this case, but it is not a best practise

LarsG: SKOS is not a best practise, because skos:Concept is not the real thing

jtandy: recommended way is the terminology for non-best practises that we agreed upon
... next theme: relating toponyms

eparsons: toponym is the name for a place

jtandy: thematic identifiers are not enough

eparsons: we need to deal with the fact that two spatial things have two different names
... e.g. Israel, Palestine

ahaller2: can we solve this we PROV?

eparsons: maybe this issue also gets resolved with the weaker relationships

jtandy: you can provide an rdf:label

ahaller2: but what if they have two different geospatial boundaries, then we can't use rdf:label

jtandy: you may need to do a further reconciliation after the label
... we need to have a best practise how you can tell us what the name for this geospatial thing is
... next theme: what to do with resources such as the Renaissance in Italy?

eparsons: this is difficult in so many aspects

jtandy: geographical locations in the past that do not correlate exactly to the modern day geospatial boundaries
... you would mint a URI for Renaissance Italy and you may have a geometry associate with it
... someone else may publish something else about the Renaissance
... and then they may agree about a reconciliation

eparsons: we have no mandate to solve the reconciliation problem

LarsG: sameTimeAs and samePlaceAs would be helpful here

kerry: these two may be very strongly linked

ahaller2: so if it is sameTimeAs and samePlaceAs it will be OWL sameAs

ddahl: what about the American West, it is a known fuzzyness

ahaller2: do we need a class for a fuzzy thing and fuzzy time

jtandy: it is just a SpatialThing

kerry: do we need to distinguish the abstract thing from the concrete thing

eparsons: boston university has done an experiment asking people to draw boundaries around boston and there was no agreement, as expected, but there could be a core subset

jtandy: SpatialThing has a spatial extend, but not necessarily a specific one
... there is already a class that we can use, a SpatialThing

LarsG: a Fuzzy Spatial Thing would be a subclass for a SpatialThing
... we need to have a means to transport the fuzziness

jtandy: rather than the class being special, we define a property that defines the fuzziness of the geospatial

ahaller2: but what if I want to say that my instance is fuzzy, but I don't want to define the geospatial boundaries

<eparsons> === Meeting Ends ====

jtandy: create issue, do we need a sub type that defines a thing with a fuzzy boundary