See also: IRC log
<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
<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
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
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.
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