W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2016

OWL-Time - RE: [Minutes] 2016-02-08

From: <Simon.Cox@csiro.au>
Date: Mon, 8 Feb 2016 22:55:13 +0000
To: <phila@w3.org>, <public-sdw-wg@w3.org>
Message-ID: <2A7346E8D9F62D4CA8D78387173A054A6035DA7D@exmbx04-cdc.nexus.csiro.au>
I noticed the discussion on OWL-Time in the minutes. 
A couple of responses: 

1. @aharth is sceptical about the size of the community that has requirements beyond what is handled by OWL-Time now. 
I discussed this briefly in my paper in Semantic Web Journal. There are the following concerns:
- pre-contemporary applications - archaeology, geology, dynastic calendars, etc
- cultural diversity - Hebrew, Arabic, Baha'i calendars, etc, even GPS time and Unix time are not currently allowed! 
The goal of my proposed changes to OWL-Time is only to allow these applications to use the same ontology, and not drive them elsewhere. These are indeed minority applications, so the solution I proposed does not disrupt existing encodings and applications - there would be no change to these. It merely adds some additional attributes to allow alternative TRS _when required_.  The default remains the status quo. 

2. Accuracy and precision - Chris can speak to these much more clearly than I can. I suspect these are more about actual practice rather than the real capability of the ontology if used properly, but Chris may have spotted some other issues. 

Simon 

-----Original Message-----
From: Phil Archer [mailto:phila@w3.org] 
Sent: Tuesday, 9 February 2016 3:57 AM
To: SDW WG Public List <public-sdw-wg@w3.org>
Subject: [Minutes] 2016-02-08

The minutes of today's f2f meeting are at 
https://www.w3.org/2016/02/08-sdw-minutes


Text version below, as ever:


           Spatial Data on the Web Working Group Teleconference

08 Feb 2016

    [2]Agenda

       [2] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3


    See also: [3]IRC log

       [3] http://www.w3.org/2016/02/08-sdw-irc


Attendees

    Present
           kerry, Linda, jtandy, LarsG, AndreaPerego, aharth,
           BartvanLeeuwen, ChrisLittle, rachel, billroberts, phila,
           frans, eparsons, ChrisLIttle, ClemensPortele,
           roblemmens, ClausStadler

    Chair
           Ed

    Scribe
           Jeremy Tandy, jtandy, phila, BartvanLeeuwen, Lars,
           aharth

Contents

      * [4]Topics
          1. [5]UCR document
          2. [6]approve the minutes (of last f2f)
          3. [7]patent call
          4. [8]new participants
          5. [9]UCR -- steps to ensure that the remaining issues
             will not stay open indefinitely
          6. [10]Use cases missing arising from recent work?
          7. [11]Time
          8. [12]Best Practices
          9. [13]Scoping
      * [14]Summary of Action Items
      * [15]Summary of Resolutions
      __________________________________________________________

    <phila_train> meeting: SDW F2F Day 1

    <Linda> Hi Kerry Ed is not here yet

    <kerry> Hi linda!

    <kerry> I have not managed to get in on webex yet eiter

    <Linda> Phil is not here yet either. So I suppose we wait a
    little...

    <kerry> ed just sent an email -- maybe 10?

    <kerry> also bill roberts said 10

    <phila_train> hi all. Text messages and emails flying around
    suggest Ed, Bill and I will arrive at Amersfoort station in one
    hour's time. I just pulled out of Rotterdam Centraal.

    <kerry> phil had said he would be late -- a few days ago --
    maybe 11?

    <BartvanLeeuwen> morning everyone

    <BartvanLeeuwen> hi kerry

    <kerry> hi bart!

    <kerry> do you have webex in the room?

    <Linda> not yet

    <BartvanLeeuwen> we are working onthat....

    <kerry> ok -- ta. It looks a bit like it might need phil to me

    <BartvanLeeuwen> kerry: but I'm not able to dail..

    <BartvanLeeuwen> as in , I can' start a audio connection

    <BartvanLeeuwen> ok, can't you 'take' over the meeting and
    become host ?

    <BartvanLeeuwen> kerry: do you have skype credits ?

    <BartvanLeeuwen> okay

    <BartvanLeeuwen> can you call long distance on someone elses
    expense ?

    <BartvanLeeuwen> whats your number ?

    <BartvanLeeuwen> for now yes

    <BartvanLeeuwen> hmmm

    <BartvanLeeuwen> that is us

    <BartvanLeeuwen> +31 number

    <BartvanLeeuwen> kerry: we will do that

    <BartvanLeeuwen> you didn't receive a call ?

    <kerry> ok, who can chair please?

    <BartvanLeeuwen> kerry: linda is chairing

    <frans> I will start with the UCR topic

    <kerry> +61 2 409788412 (maybe fogot to drop the zero)

    <jtandy> scribenick: jtandy

    <kerry> +61 409788412

    <scribe> scribe: Jeremy Tandy

    <kerry> trackbot, start meeting

UCR document

    <trackbot> Meeting: Spatial Data on the Web Working Group
    Teleconference

    <trackbot> Date: 08 February 2016

    [we finally get some audio working on the teleconference]

    <kerry> scribe: jtandy

    <kerry> chair: kerry

    <scribe> scribenick: jtandy

    <kerry> scribenick jtandy

approve the minutes (of last f2f)

    kerry: did we approve the minutes of the last f2f?

    [looking]

    <kerry> [16]https://www.w3.org/2015/10/25-sdw-minutes


      [16] https://www.w3.org/2015/10/25-sdw-minutes


    jtandy: query- the minutes from sapporo

    kerry: yes- 2-days

    propose: approve sapporo f2f minutes

    +1

    <BartvanLeeuwen> +1

    <frans> day two: [17]https://www.w3.org/2015/10/26-sdw-minutes


      [17] https://www.w3.org/2015/10/26-sdw-minutes


    <Linda> +1

    <frans> +1

    <kerry> +1

    <AndreaPerego> +1 (I was not there, but I trust you)

    RESOLUTION: approve sapporo f2f minutes

    <ChrisLittle> +0 not there

patent call

    <kerry> [18]https://www.w3.org/2015/10/26-sdw-minutes


      [18] https://www.w3.org/2015/10/26-sdw-minutes


    propose: approve sapporo f2f minutes day 2

    +1

    <kerry> +1

    <BartvanLeeuwen> +1

    <Linda> +1

    <frans> +1 (I was not there, but I trust you)

    RESOLUTION: approve sapporo f2f minutes day 2

    <LarsG> +1

    kerry: BIG thankyou to Linda and Geonovum for hosting the F2F
    ...
    ... does the patent call

    <Linda> You're very welcome! Nice having you all here.

    <kerry> [19]https://www.w3.org/2015/spatial/wiki/Patent_Call


      [19] https://www.w3.org/2015/spatial/wiki/Patent_Call


    kerry: reminds people that this follows both W3C and OGC
    process; particularly for OGC, please declare patent interests
    ...
    ... let me know of anything

    Linda: we have two new people in the group today; Rob and Stan
    ...
    ... from OGC

    jtandy: asks Rob and Stan to type their intro into the IRC
    after they do their verbal intro

new participants

    <roblemmens> Intro Rob Lemmens

    frans: says great to have you with us ... hopefully you can
    provide real examples

    kerry: [Rob and Stan] are already OGC members ... welcome
    ... gives some IRC advice to the newcomers

    <roblemmens> We're ITC, Univ Twente, working on visual linked
    geodata explorer and VGI ontology

    kerry: to the agenda ...
    [20]https://www.w3.org/2015/spatial/wiki/Agenda_F2F3


      [20] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3


UCR -- steps to ensure that the remaining issues will not stay open
indefinitely

    kerry: invites frans to lead ...

    frans: lists the open actions on the screen
    [21]https://www.w3.org/2015/spatial/track/actions/open

    ... there's [quite a large number]
    ... there has been discussion on the email list, so that
    probably means these aren't trivial to resolve
    ... but we need to finish the requirements before we get on
    with the work
    ... otherwise things are being done backward
    ... it's good to take a look at these issues again now
    ... we actions in the tracker to get things done
    ... we assigned actions for the deliverables to particular
    people
    ... we can't allocate to multiple people

      [21] https://www.w3.org/2015/spatial/track/actions/open


    kerry: suggests that we operate in a bit of an agile fashion
    ...
    ... leave some requirements open whilst we don't have resources
    to work on them
    ... also, the timeline shows we have plenty of time for the UCR
    ... we don't need to resolve all issues up front

    frans: I got the impression that some of these issues are not
    resolved because they're difficult
    ... not because we're not working on them yet
    ... difficult does not mean important

    kerry: fair enough - seems reasonable to review these actions
    [periodically]
    ... but they don't have to be resolved where we are not
    actively working on the deliverables

    frans: OK - the intention was not to shift the work, just to
    begin collaboration with these folks
    ... the other deliverable editors can then help prioritise
    which issues to focus on
    ... in some cases, we just need to synthesize the discussions
    [to form a conclusion]

    kerry: what we could do for SSN in particular, is add these
    issues to tomorrow's agenda
    ... for the others, it's a bit harder, because they're not
    started yet

    frans: seems sensible!

    kerry: better to try to resolve these actions F2F ...
    ... time deliverable - we might be able to do that
    ... coverages deliverable - not really started yet
    ... does that help?

    frans: it's good to make sure that the deliverables have a good
    chain of requirements
    ... [with assoc use cases]
    ... I see that BP and SSN have already been through this phase

    kerry: tracking deliverables back to requirements and use cases
    is a good idea
    ... wouldn't say that SSN has done this yet - BP have done this
    and this might provide an exemplar to follow
    ... question to frans - are there any specific actions / issues
    you want to resolve?

    frans: not a good idea to go into the details now - because
    these are difficult, we'll loose a lot of time
    ... let's try to keep the UCR doc up to date with the work of
    the deliverables

    kerry: we do have _some_ time right now
    ... we could try a couple of the harder ones right now
    ... are there any?

    frans: asks for volunteers :-)
    ... how about CRS?

    <Linda> jtandy: re CRS requirement

    <kerry> jtandy: best practice addresses crs

    <kerry> ...by taking some of the heat away..

    <Linda> ... in the BP we are explaining when you need another
    CRS than WGS84. Do we think that's a good approach and would it
    resolve the action?

    <kerry> fantastic! -- i liked what i saw on this in the BP

    <LarsG> jtandy: we need guidance on when WGS84 is not enough
    and when the publisher needs to be explicit (and how to do it)

    <LarsG> ... this also goes into geometry etc.

    <LarsG> ... How are we able to meet the requirement we've got

    <LarsG> frans: But we've been unable to specify requirments

    <LarsG> jtandy: But isn't the req: when is WGS84 not enough and
    what do I do when not?

    <LarsG> frans: Has problem with the way it's done in geosparql
    (conflating CRS URI with geometry)

    <LarsG> ... BP editors can try to formulate requirements as the
    BP document progresses

    ChrisLittle: just to follow up frans comment about chaining
    back to requirements and use cases
    ... the spreadsheet we produced
    ... is it deficient?

    frans: we stopped working on that
    ... it was just input to our UCR FPWD

    kerry: did we resolve the CRS issue?

    jtandy: responds [...]

    <rachel> e.g. in geojson when you specify CRS other than WGS84
    most mapping applications that read geojson just ignore that
    and try to plot it as WGS84. The applications need to show an
    “unsupported crs” message

    jtandy: noting that frans encouraged the BP editors to write
    down what they understood were the requirements

    kerry: can we write these in the TRACKER now????
    ... please :-)

    BartvanLeeuwen: asks that we have a short break to organise
    webex connection

    [... short break ...]

    <rachel> ...in other words, requirement that CRS issue needs to
    be solved on consumer end as well as publisher

    [@rachel ... yes I think so]

    <BartvanLeeuwen> kerry: do you hear us ?

    <ChrisLittle_> bye

    jtandy: asks frans to tell us where we got to ...

    <eparsons> Morning !!

    [resuming ...]

    frans: so we've done topic for point 1
    "[22]https://www.w3.org/2015/spatial/track/actions/open"
    ... before we finish that, are there any other volunteers to
    talk about open issues

      [22] https://www.w3.org/2015/spatial/track/actions/open


    <kerry> chair: eparsons

    frans: what about ChrisLittle - he sent an email about time
    requirements

    ChrisLittle: no - I think we're fine there

    frans: also - what about SSN folks?
    ... there's still an open action to turn the reqs from the SSN
    incubator group into use cases [?]
    ... that's a question to kerry: are there still missing SSN
    requirements in the doc

    kerry: I put a summary on the mailing list to cover this
    ... still an open action on me
    ... leave at that for now and remind me again
    ... I've done the analysis

    frans: can we do that at the same time as we go through the
    wiki page for SSN requirements?
    ... is that possible?

    kerry: ... hmmm ... hmmm ... yes

    eparsons: what's the doubt?

    kerry: there isn't one
    ... the wish list is 98% constructed by me; it's not the
    original incubator group list, its what people have asked me
    for
    ... these might not actually constitute _requirements_

    eparsons: [agrees] we need to trim the wishlist; having more
    concrete requirements might help this
    ... is this a good mechanism [for managing the scope] of the
    SSN deliverable

    kerry: yes ...
    ... we can keep the bigger list for context

    eparsons: thanks kerry - that helps

    kerry: notes that in the spirit of W3C chair training, have a
    wishlist of things that you _want_ to do, but might not have
    the resources to get to
    ... the SSN wishlist is done in that spirit

    frans: no other volunteers?
    ... we've talked about trying to sync the UCR with other
    deliverables ...
    ... let's move to the next topic

    <kerry> [23]https://www.w3.org/2015/spatial/wiki/SSN_Wish_List

    is the "wish list" of things for ssn I have picked up

      [23] https://www.w3.org/2015/spatial/wiki/SSN_Wish_List


Use cases missing arising from recent work?

    <phila> Thansk Kerry

    frans: I have a new use case ... the web is a distributed
    system
    ... it's not always easy to find what you need
    ... does the BP doc provide a solution to this?

    billroberts: we can't provide a _complete_ resource

    eparsons: [agrees] we provide a starting point

    frans: proposes that we add this use case, and explicitly say
    that the BP doc resolves this

    eparsons: this could work - the link has always been implicit,
    it would hurt to make this explicit
    ... what do the BP editors think?

    Linda: hmmm ...

    frans: so the BP doc provides a starting point to get people
    going.
    ... similar to the "linked data book" that I started with for
    that topic

    Linda: yes- this could work

    ChrisLittle: the only thing that's not explicit in the charter
    that was provide the _single point of reference_
    ... we provide some best practice

    eparsons: we're not trying to be canonical
    ... it's only as good as it is when the doc is published
    ... it's ok to have this "meta requirement"
    ... but don't oversell this as the "final word"
    ... maybe what we need is a _short_ summary that helps people
    get started; the BP doc will [likely] be quite long

    frans: yes - the BP doc needs to be read in many ways

    <phila> jtandy: I noted that you cited the Linked data books as
    a place to learn about that. Are you hoping that the BP doc
    will be as informative?

    <phila> frans: It's called a book but it's a single Web page

    <phila> billroberts: It's the one Tom Heath did

    <BartvanLeeuwen> [24]http://linkeddatabook.com/editions/1.0/


      [24] http://linkeddatabook.com/editions/1.0/


    <phila> frans: It was a complete narrative with pointers to
    relevant information so if you needed to pick a single starting
    point, it was a good one

    eparsons: @frans ... you've given yourself a task to write the
    requirement there

    <phila> frans: I think that's something to keep in mind when
    writing the Bp doc

    <phila> BartvanLeeuwen: I think there's so much info around
    about spatial data, it's hard to create a single starting point

    <phila> BartvanLeeuwen: But I like the objective

    <scribe> scribe: phila

    eparsons: We recognise that we're not starting with a blank
    sheet of paper
    ... We're opening up that info

    <scribe> scribe: phila

    <scribe> scribeNick: phila

    jtandy: I'm concerned that we're setting ourself too big a
    target
    ... I don't think we can aim for publishing a complete ref for
    spatial data
    ... We should limit our focus to getting spatial data 'on the
    Web' - although I don't think we all agree what that means
    ... not about spatial data in general

    eparsons: We should recognise 2 broad communiites. Someone who
    is publishing spatial data for the first time
    ... the other one is slightly different. I already have data
    that I probably already publish using OGC services
    ... but I need to do x y z
    ... So they start from different points and therefore need to
    give them both a starting point.
    ... You're a good citizen of the Web, it's about URIs, etc.
    ... It doesn't need to be an encyclopaedia

    frans: If you say on one side that you have a requirement but
    we can also say that we can't necessarily meet them all.

    jtandy: When you word this requirememnt, pls make sure you're
    talking about publishing spatial data on the Web.

    ChrisLittle: The contents of the LD book - there's some good
    structure there you can reuse (nick)

    <eparsons> action frans "to write meta requirement that the BP
    will provide guidance to spatial data publishing"

    <trackbot> Created ACTION-135 - "to write meta requirement that
    the bp will provide guidance to spatial data publishing" [on
    Frans Knibbe - due 2016-02-15].

    jtandy: We have an action to think about how to structure the
    BPs to give people an 'in'
    ... especially for people with a short attention span

    frans: Are thereany other use cases arising from recent work.

    roblemmens: We're new of course. I've been looking at the UCR
    and BP doc
    ... I've been looking at the VGI paradigm. Are there use cases
    for that?

    <eparsons> VGI

    <AndreaPerego> Another source to look into is "Linked Data
    Patterns" (by Ian Davis and Leigh Dodds):
    [25]http://patterns.dataincubator.org/book/


      [25] http://patterns.dataincubator.org/book/


    <eparsons>
    [26]https://en.wikipedia.org/wiki/Volunteered_geographic_inform

    ation

      [26] https://en.wikipedia.org/wiki/Volunteered_geographic_information


    roblemmens: I saw some frontier issues in the UCR, but maybe
    they're spread here and there. It's related to provenance of
    course.
    ... For those datasets, you want to know how they came into
    being

    <ChrisLittle> +1 to roblemmens comment

    frans: We have this general discoverability requirement that
    everyone thinks is important. Not going far enough?

    roblemmens: You have data in general, but volunteered data...

    s/froniter/volunteered/

    <jtandy> +1 to @roblemmens thoughts about VGI; especially
    regarding provenance of that info

    eparsons: Playing devil's advocate - don't issues of provenance
    solve that?
    ... All that's different is the people who create it
    ... If you know that this temperature record was made by the
    Met office vs. someone in their garden, that tells you what you
    need, no?

    roblemmens: But they sometimes form communities that have a
    common purpose, and that is also discoverable.

    jtandy: So we tried to pick up the VGI stuff in the BP doc. In
    many situations where people are volunteering that info,
    they're using existing channels, like Twitter
    ... So you end up with unstructured info that the service will
    probably have to process.
    ... But yes, VGI is often as structured as official info. OSM
    is an obvious example.

    ChrisLittle: Ancenstry info is an example., In the UK they've
    all agreed to use pre-1972 boundary change data

    roblemmens: OK, but there are different levels of formality,
    and depending on that you may need to do more or less
    pre-processing

    <kerry>
    [27]https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Crow

    d_sourced_earthquake_observation_information_.28Best_Practice.2
    CSSN.29

      [27] 
https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Crowd_sourced_earthquake_observation_information_.28Best_Practice.2CSSN.29


    kerry: I wanted to point to that use case ^^
    ... It's a VGI use case, not sure if it made it into the UCR
    ... This talks about official info that is volunteered.
    ... So maybe we've already covered it?

    eparsons: Asks roblemmens to look through the requirements to
    see if VGI is covered sufficienetly.

    roblemmens: Yes, OK. I'm not sying it's missing, I'm just
    checking that it has been discussed.

    Linda: Do we have requirements on provenance.

    frans: Prov is a general data issue
    ... So this req is about alignment with existing practices.

    <eparsons> action roblemmens Review current Reqs and add one if
    needed for VGI issues

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

      [28] http://www.w3.org/2015/spatial/track/users


    frans: Many issues that people deal with, like prov, is not
    specially spatial

    Linda: responding to Frans' question about additional UCRs. I
    sent an e-mail to the list a while back with an addition to the
    construction use case
    ... Do you intend to add that Frans?

    frans: I think more discussion is needed. I had questions about
    it - I created an issue so it won't be forgotten.

    Linda: So let's discuss..

    issue-38

    <trackbot> issue-38 -- decide if and how to add the proposed
    use case -- raised

    <trackbot> [29]http://www.w3.org/2015/spatial/track/issues/38


      [29] http://www.w3.org/2015/spatial/track/issues/38


    Linda: This is from the construction industry. They find they
    have to integrate data as construction is in progress.
    ... Some data is about real world things, some data is about
    virtual things/records in a database. Those differences matter
    of course. So we need some way to model these things.
    ... They wrote their whole use case down and I'm hoping it can
    be added to the UCR.

    ->
    [30]https://lists.w3.org/Archives/Public/public-sdw-wg/2016Feb/

    0018.html E-mail thread

      [30] 
https://lists.w3.org/Archives/Public/public-sdw-wg/2016Feb/0018.html


    Linda: The key thing is that difference in perspective
    ... They talk about the chart perspective/map perspective.
    Those are the spatial things and they need to integrate that
    with the real world.

    phila: Waffles on about HR14
    ... Emphasising that a URI is a dumb string and you don't know
    what it identifies until you dereference it

    eparsons: Yes, we do need to think about it. In the spatial
    world, we only talk about data about real world things.

    frans: We don't have the same confusion

    <jtandy> [note: we had this discussion on the mailing list, see
    thread:
    [31]https://lists.w3.org/Archives/Public/public-sdw-wg/2015Oct/

    0125.html]

      [31] 
https://lists.w3.org/Archives/Public/public-sdw-wg/2015Oct/0125.html]

    eparsons: I think we do, in that don't think in terms of the
    physical thing that you can walk into

    billroberts: You can't think in terms of who owns the spatial
    data, you think about who owns the building.

    ChrisLittle: The building would be a point on a map

    <jtandy> [also see URLs in data primer, W3C WD
    [32]https://www.w3.org/TR/urls-in-data/]

      [32] https://www.w3.org/TR/urls-in-data/]

    ChrisLittle: then you get closer and it has extent and so s

    frans: That's an issue, you have multiple representations of
    the thing. The idea of having to do something with the real
    world thing never arises.

    LarsG: You said, it's not your problem, Frans, but someone else
    will have the problem.
    ... If we don't separate the thing from the metadata, that
    might not be a problem for you but it might create a problem
    downstream.

    jtandy: I just wanted to highlight that we had a lot if this
    discussion on the email thread. We also discussed it f2f in
    Saporro

    <kerry> s/saporro/Sapporo/

    jtandy: A guy called Tim said that, yes, we've talked about
    this for a long time and in the end people generally think it
    really doesn't matter. using a VCard as a proxy for the person
    is commonly done and we need to get over it.
    ... We can use 'punning' so that we can treat it as a real
    world thing or a record.

    frans: Can we ignore it unless it becomes a problem.

    jtandy: SDOs have this problem. But schema.org looks at what
    people do and people do this all the time...

    billroberts: Is anyone sufficiently familiar with Jeni's work
    on trying to solve this?

    -> [33]https://www.w3.org/TR/urls-in-data/ URLS in Data

      [33] https://www.w3.org/TR/urls-in-data/


    jtandy: What she said is - the best thing to do is to give
    differnet identifiers for the real world thing and the record.
    Most of you don't, but if you don't, it would be helpful if you
    ...
    ... distinguished between a direct property about the thing
    itself (creation date etc.) and an indirect one about the page
    about the thing.

    frans: So that's an example where people use web pages as the
    real thing.

    Linda: That's what this use case from the construction industry
    is about. They need to make that distinction.
    ... I think one of them is coming to the workshop on Wednesday.

    BartvanLeeuwen: I was amused that HR14 comes up in every F2F
    meeting I've ever been to.
    ... I am sympathetic with Frans's view of ignoring it until and
    if it bites us.
    ... But we might get comments...
    ... In the end, we are probably going to have to formulate an
    answer.

    <Zakim> LarsG, you wanted to talk about licensing content vs
    licensing metadata

    frans: Points to some proposed text... you mint a URI for the
    building ...

    (lost some detail)

    jtandy: INSPIRE gives identifiers to information records. And
    then you have thematic identifiers and these can be confusing.
    ... I think we're saying that you should create a URI for the
    real thing.

    LarsG: We've said in the library world that we need differnet
    URIs for the document and metadata about the doc.
    ... There's a huge difference in the licensing of the two

    AndreaPerego: We had the same in DCAT which has the datasets
    and catalogue records.
    ... It's usually the record that gets the reliable URI.
    ... It's probably related to how we use the IDs.
    ... Any feedback on the UK work on URIs for spatial objects?
    ... Did it meet the requirements?

    phila: That work is withering on the vine, not because it isn't
    good, but because the individuals are otherwise engaged.

    jtandy: Since that work, there seems to have been a groundswell
    of using the context to determine whether we're talking about
    the real world thing or the data.

    eparsons: I have an app on my phone that opens the door to my
    hotel.
    ... So my phone is interacting with a real world thing

    <jtandy> [wow - he can use bluetooth LE to open the lock on the
    door after online check-in!]

    eparsons: We can skirt around it but I think we do have to draw
    that line in the sand and say that it is going to be necessary
    to have different identifiers for the two. And that would be BP

    <jtandy> [key point is that we need to be _clear_ which is the
    real world lock, which is the information record about that
    lock]

    Linda: They're not trying to describe the building, they're
    trying to integrate different datasets related to the building.

    eparsons: Talks about links between thing and n records about
    the thing.

    AndreaPerego: The catalogue record is defined in the context of
    the catalogue, it's not an absolute resource.
    ... In this case, the prov of the metadata is important. It's
    important to tell the record from the description of the
    resource and the resource itself.
    ... It makes sense to me to apply that as a general requirement
    for data on the Web.

    frans: So the req from this use case is being able to integrate
    data with different perspectives.
    ... I'm looking for a case where the difference really matters.

    <Zakim> jtandy, you wanted to note that we can make general
    statements about data on the web- but through a spatial lens

    eparsons: My lock on the door is my example

    billroberts: We need to be careful not to be drowned in the
    swamp of HTTP Range 14

    eparsons: I think it's a bigger issue for the spatial community
    than it is for the general data community.
    ... We're both communities that have grown up digitising
    representations of the real world. But now we're seeing more
    need to refer to the real world thing.

    <scribe> ACTION: frans to clarify use case requring
    differentiation between real world and representation
    identifers, during Wendesday's workshop [recorded in
    [34]http://www.w3.org/2016/02/08-sdw-minutes.html#action01]

      [34] http://www.w3.org/2016/02/08-sdw-minutes.html#action01]

    <trackbot> Created ACTION-136 - Clarify use case requring
    differentiation between real world and representation
    identifers, during wendesday's workshop [on Frans Knibbe - due
    2016-02-15].

    jtandy: I think we're Ok to cover this as long as we show the
    issue through the spatial lens.

    eparsons: Any more UCR issues to tackle?

    kerry: I don't have another use case, but I was going to
    suggest we might move on to the topic of @@ ?

    eparsons: Can you clarify who is coming on Wednesday?

    Linda: Our regular Platform Linked data Nederland will be here.
    Some are very technical, RDF heads, others are more business
    ... Come from academia, business etc.
    ... This Wednesday we have a lot coming from outside NL
    ... There's a EURO SDR workshop as well as us so that's
    increasing interest

    eparsons: Thayt's more cadstral, mapping agencies, IGN etc.

    Linda: The theme of the meeting is Spatial Data on the Web.
    More from Geo world than normal. 160 registered

    eparsons: Have we thought about how we want to do this? Picking
    some UCs that we think might be useful cf. asking for ideas for
    UCs?

    jtandy: Linda asked me to give a 10 minute talk on what we're
    doing with a focus on the BP doc. The people working on the
    Geonovum tender will be there too.
    ... All I'd mention in terms of UCs, the 30 BPs we have so far
    are underpinned by multiple UCs.
    ... We have a parallel threada. If people want to engage with
    this group, then the // thread is the way to do that.

    Linda: So not all 160 people will be in the workshop - which is
    good as the room isn't that big.
    ... So we'll have about 1.5 hours to engage with those folks.

    jtandy: I'm explicitly asking them... we need you if we're to
    provide something useful to you.
    ... So really asking for help with what they need help with.

    (scribe paraphrase)

    roblemmens: Maybe a short walk through the document?

    jtandy: We could do that in the // track?

    eparsons: This is about doing a santity check on the work we've
    done, talking to customers.
    ... I would hope that there won't be loads of new use cases
    popping up. WE perhaps shouldn't fish for new UCs.

    frans: If there are any, it's better to have them ASAP.

    eparsons: Yes, but I don't want to put UCs front and centre.
    The view into the use cases is probably going to be the BP doc.
    If there's something misisng, let us know.

    jtandy: if there's something grossly missing, tell us the use
    case and cite the real world case where this is important.
    ... We may be able to amend an existing UC to include that.
    ... But we can't take pet projects.

    ->
    [35]http://www.pilod.nl/wiki/Geodata_on_The_Web_Event_10_Februa

    ry_2016 Workshop website

      [35] 
http://www.pilod.nl/wiki/Geodata_on_The_Web_Event_10_February_2016


    eparsons: We've done a lot of homework gathering these UCs.
    This isn't our pet project - we have evidence that these things
    are important.

    jtandy: I'll give a short plenary talk at the start, and then
    in our // track we can have the full conversation.

    frans: I agree with not fishing for new use cases, but we can
    seek new requirements

    jtandy: And they need to be hooked on to an existing UC.

Time

    ChrisLittle: We've talked about this before. Time is not
    specifically spatial - it's more fundamental than that.
    ... There's a lot of confusion and mix up of time and dates.

    eparsons: So what is the real problem.

    ChrisLittle: The real problem is the confusion between precison
    and accuracy
    ... ISO 8601 gives you a false sense...
    ... It's the same as the confusion with WGS84.
    ... If you don't care about precision to the nearest minute,
    then OK.

    jtandy: many communities ignore what other people want.
    ... It's when we look in from the outside, it doesn't
    necessarily line up.

    eparsons: We have a bunch of expert communities who know more
    than we do.

    jtandy: Our biggest problem is that there is no formal way of
    writing down time as an ontology.
    ... If Simon were here, he'd say there is no way to talk about
    non-Gregorian calendars, or indeed ones that include leap
    seconds.
    ... cretaceous period etc. Lots of things it doesn't do.
    ... Our charter asks us to finish the work off. It matters when
    something is where.

    <AndreaPerego> s/peroiod/period/

    frans: To respond to Chris's remark on precision and accuracy -
    it's a general data thing, not spatial.

    <rachel> s/whewn/when/

    frans: Maybe we can ask the DWBP about this.
    ... Maybe we should make a list of things to talk to DWBP about
    on the call next week (17/2)

    eparsons: anyone else?

    aharth: I think it's a problem that we don't have an onology
    for time - but our use cases don't say that. An ontology is a
    long way from the UCs.
    ... ISO 8601 gets you a long way. How big is the community that
    need non-Gregorian time?

    <eparsons> action ChrisLittle "bring up time issues with DWG on
    next weeks telecon"

    <trackbot> Created ACTION-137 - "bring up time issues with dwg
    on next weeks telecon" [on Chris Little - due 2016-02-15].

    ChrisLittle: The problem is that ISO8601 allows accuracy but
    it's not precise. It doesn't include leap seconds so GPS time
    is currentely 30 adrift from the real time.

    aharth: So who cares?

    ChrisLittle: The defence community thinks it's a big problem.
    Just as people think of bombing the wrong place, you can be
    equally inaccurate about when.
    ... We're committed to leap seconds until at least 2022. So
    we'll move a few more seconds adrift from real time.

    <Zakim> jtandy, you wanted to talk about archaeology

    ChrisLittle: There are use cases of people trying to extract
    meteorological info from old ships logs. If you write down
    gthat info, which calendar were they using?

    <rachel> s/sheeps/ships/

    jtandy: We have use cases from archaeological and cultural
    history
    ... And geologists who want to talk agbout the anthropocene

    aharth: Is unconvinced. I don't think the community is a big
    one. If we look at things like SSN...

    ChrisLittle: becomes animated
    ... Let's talk about the IoT people - a growing community. Each
    of those things will have a time on them. But where does that
    time come from.
    ... Different computers may have different times. They need to
    be synchronised.

    eparsons: It works now, doesn't it?

    ChrisLittle: Not really, it might.

    aharth: It's about raising a flag about the difference between
    accuracy and precision.

    <Zakim> phila, you wanted to ask about internet time

    eparsons: Internet time generally runs of GPS time
    ... We've signed up to finishing the ontology about time. We
    just need to make sure it fits within the community we're
    serving.

    ChrisLittle: My concern is that as we fix the OWl ontology, we
    need to go beyond spatial context.

    roblemmens: A more prinicpalled problem - often there is no
    time label at all, when sometimes you need it.
    ... You find the spatial data but you don't know when it was
    true.
    ... But that has nothing to do with the ontology as such.

    frans: It's common practice to use XML schema datatypes
    ... Most standards seem to recommend xsd:dateTime which goes to
    a time
    ... So false info is created

    roblemmens: That's why time labels are often missing

    frans: The other thing I wanted to say... some communities
    don't have a big Web presence at the moment. We shouldn't only
    look at current Web presence - some may be waiting for us to
    help them.
    ... So we should look at some who are not really on the Web
    yet. people dealing with professional data, gov data,
    historical data.

    kerry: I wanted to say ... this is something I've been troubled
    with. What does SSN look like? Yes, it's an ontology. But we
    need to talk about how to use it.
    ... I don't think I'd include that in the BP doc.
    ... It's within scope if we have the resources.

    <ChrisLittle> +1 to Kerry's comments

    <eparsons> +1 to kerry

    kerry: So I think we need to talk about time and how to handle
    it on the Web.

    <kerry> [36]https://www.w3.org/2015/spatial/wiki/Time_Wish_List


      [36] https://www.w3.org/2015/spatial/wiki/Time_Wish_List


    kerry: Modulo a check over the UCs, I think this pretty much
    covers things on the e-mail list.
    ... Maybe that's enough?
    ... I'd like us to talk about how to use this.

    eparsons: What's you sense, ChrisLittle, if the work is
    completed - how much does that solve where the issues are and
    how much does the BP doc need to give a narrative.

    ChrisLittle: I think fixes to the ontology will help encourage
    better practice.
    ... People use 8601 time when they don't really mean it because
    that's what the javascript libraray offers.

    <Zakim> jtandy, you wanted to say that BP editors intend to use
    examples to illustrate how time should be used properly

    jtandy: BP editors... section 6.2.3 which talks about temporal
    aspects of data that currently has no BPs in it.
    ... What we thought we'd do, rather than talk about that, was
    to use examples of how we write spatial data that had temporal
    aspects.
    ... I'm sure there's more work to do there to cover archaeology
    etc.
    ... That's where I'd like to show people how to do it properly.

    eparsons: But there's still that wider requirement around
    spatiotemporal. The time ontology has a wider scope than ours.

    jtandy: I think the work has more or less been done. Simon has
    written his proposal for extending the time ontology to cover
    non-Gregorian stuff.
    ... I'd take what Simon has done and see if it meets our needs

    ChrisLittle: I think we need some BP exemplars, saying don't do
    this etc.
    ... Just as we do on precision and accuraxcy on CRSs

    phila: Can Simon publish what he's done as a ReSpec document?

    BartvanLeeuwen: Since we said a long time ago that we'd talk
    about best practice, not best theory.
    ... How do you say that this building was built in 1980 in LD?
    There's no BP for that yet.

    eparsons: To be brutal, our charter says we'll do the time
    ontology. We haven't said we'll give BPs on how to use it.
    ... We're all going to be time pushed this year.

    kerry: I was going to say, in terms of Time Ontology
    influencing BPs, there's plenty out there already.

    <kerry> [37]https://www.w3.org/2015/spatial/wiki/Time_Wish_List


      [37] https://www.w3.org/2015/spatial/wiki/Time_Wish_List


    kerry: There's a lot on that list already

    <Zakim> phila, you wanted to say BPs for time not needed

    phila: Talks about diff between implementation experience -
    needed for the Recs - and BPs, which will come later.
    ... Explains kind of evidence needed to get to rec for an
    ontology. Each term used in data >= 2 times

    (scribe missed aharth's point, because it's lunch time)

    <Zakim> AndreaPerego, you wanted to ask about time URIs and the
    use of Time ontology by reference.data.gov.uk

    AndreaPerego: We haven't talked about the UK time URIs. You get
    back time ontology data
    ... Do we think they're good?
    ... Also I'd be interested in experience of using them.

    billroberts: We have used those time interval URIs in data
    quite a lot. There is the question of what is the point of
    doing that rather than using a literal.
    ... Not all the would be literals are convenient

    <eparsons> @kerry might finish a few mins early

    billroberts: and it allows you to have a time as the subject.
    ... The downside is that you can't always take advantage of
    some of the SPARQL features for ordering
    ... although the URIs can be ordered.

    AndreaPerego: I think Ian Davis did some work on this and
    geometries for time and space
    ... I think maybe you, Bill, made comments about having URIs
    for geometries in different formats
    ... I think these topics are very internlinked.

    <aharth> phila: my point was that OWL Time depends heavily on
    OWL 2 DL, but I don't know whether reasoners exist that support
    the translation from xsd:date to OWL Time and back

    ChrisLittle: When you have geometries in space, you can
    recognise difference based on CRS. Most time formats look
    similar and people assume that there is no transformation but
    that's not right.

    billroberts: I need to understand these differences.

    eparsons: Straw man - we need to get the ontology to a point
    where it becomes a Rec later this year. To cover these other
    aspects about best practice, not BP, maybe we need to have key
    references in the BP doc.
    ... We don't have other mechanisms to get things out.

    akc me

    <Zakim> phila, you wanted to talk about cross links

    <jtandy> +1 ... agree with eparsons

    phila: Talks about linking from the BP doc to all 3 of our
    other docs

    <Linda> +1 to having key references to time issues in the BP
    doc

    eparsons: We all need food

    == Lunch ==

    <eparsons> Returning from Lunch...

    <BartvanLeeuwen> scribe: BartvanLeeuwen

    <scribe> scribenick: BartvanLeeuwen

Best Practices

    jtandy: pointers to real examples in the wild
    ... we need to provide real examples, examples need to be
    informative, short
    ... it needs massaging to get them compact enough to get into
    our document

    <ChrisLittle> * no idea why I keep timiing out (sic)

    jtandy: the working group asked us for examples from the BP's
    ... we need you ( The WG ) to give us these examples

    eparsons: I hunted long and hard to use schema.org to have a
    best practice around that

    <eparsons> [38]http://queue.acm.org/detail.cfm?id=2857276


      [38] http://queue.acm.org/detail.cfm?id=2857276


    eparsons: I came up with this article
    ... it was the best place I could find to show what schema.org
    can do, and described in the best way

    jtandy: which best practices does this apply to

    eparsons: that is the issue, there are multiple, discoverabilty
    / findabilty
    ... will we extract multiple best practices, or one document
    which reference multiple BP's

    jtandy: this is one of the challenges of the document, we might
    end up with 120 examples
    ... in the BP's themselves we try to pull out snippets of the
    examples, which show you how to do small things
    ... have the full examples reference the BP's which contain the
    snippets.
    ... we also might want to reference external resources where
    things are working together
    ... do we want something like jsfiddle to let people play with
    examples.

    eparsons: how much of examples do you want to show it is real,
    and how much do you want the examples to be usefull

    jtandy: the first is about 'this is practice, not theory', the
    examples in the document are illustrative
    ... we might say this illustrative example is composed of a
    certain example in the wild

    frans: there is case to be made to create your own examples,
    examples in the wild my disappear. We need small concise
    examples where examples in the wild my be containing multiple
    BP's

    jtandy: this is a good point, its similar to what I was
    suggesting.
    ... we need ilustrative examples that we 'own' but they should
    point to examples in the wild

    <rachel> +1 to illustrative easy to read examples (patterns)
    and real uses in the wild

    eparsons: we use small snippets to explain how to implement a
    BP, but also point to real world examples

    jtandy: we might want to have fixed set of examples which hang
    together, which we could publish as a appendix

    eparsons: we need to think about a sample. e.g. acme.org which
    wants to publish data

    BartvanLeeuwen: it needs the BP's to be reordered

    <billroberts> BartvanLeeuwen makes a presentation on work with
    Dutch fire department

    <billroberts> ...supplement a WFS with additional information
    about each feature

    <billroberts> ...help the user understand the
    meaning/background of the geo features they are looking at

    <billroberts> ...Bart added a new feature name, to connect the
    feature to the thing it is about

    <billroberts> ...(rdf:about in Bart's example, but that choice
    is up for discussion)

    <billroberts> frans: there are mechanisms already in WFS to use
    XML schema to do this

    <billroberts> eparsons: we should agree a standard way to do
    this. Which way is for us to discuss

    <billroberts> BartvanLeeuwen: also wants a backlink. If you
    know the thing of interest, how do you find a WFS URL for that
    thing

    <billroberts> eparsons: most valuable thing may be simply to
    put the extra field into the standard WFS response

    <billroberts> BartvanLeeuwen: it's hard for the fire department
    users to figure this out in the middle of the night. Need to
    make it standardised and hence easier

    <billroberts> jtandy: for the BP, a tangible example, such as
    emergency response, could make a good consistent thread that we
    could use in several examples, to help make the BP doc more
    coherent and easier to understand

    <billroberts> BartvanLeeuwen: the Dutch fire department would
    definitely be interested and an emergency response example
    makes it particularly relevant for them

    <billroberts> eparsons: which of the best practices would
    Bart's example be appropriate for?

    <billroberts> agreement that there are several relevant BPs for
    this example

    <billroberts> stanislav: there is a lot of relevant data
    around, eg from cadastral services

    <billroberts> jtandy: challenge for users of WFS is that in
    many cases the only info a user can get is from the layer names

    <billroberts> eparsons: one could argue that metadata
    catalogues would help with that problem

    <billroberts> eparsons: nice idea, but need more than just Bart
    to work on it, because of volume of work

    <billroberts> frans: other gruops are working on similar
    things: how to modify WFS to be more 'webby'

    <billroberts> [BartvanLeeuwen highlights a diagram in the
    presentation]

    <eparsons> @kerry may have lets check...

    <billroberts> BartvanLeeuwen: system uses Geoserver to do WFS
    plus PostGIS with R2RML to create RDF, with the RDF connected
    in a 1:1 mapping with the WFS

    <billroberts> stanislav: there is software LOD4WFS that can
    help in creating new RDF for publishing via WFS

    <billroberts> BartvanLeeuwen: how can I create a triple which
    has a WFS URL as object? to relate other data to the relevant
    WFS

    <billroberts> Frans: why do this?

    <billroberts> BartvanLeeuwen: to support various user
    communities as well as we can

    <billroberts> jtandy: work in Australia (didn't catch who?) on
    publishing identifiers for places and links to info about them

    <eparsons> Aussie chap Rob Atkinson

    <billroberts> jtandy: value for this group is to bring together
    the RDF and WFS communities

    <ClausStadler> (hi, what's the webex meeting password?)

    <ClausStadler> ah nm

    <billroberts> eparsons: if we can't point to existing best
    practices, can present our preferred option (even if not yet
    well established)

    <billroberts> eparsons: not so helpful if we say, well you
    could do one of 4 things. Better to be specifci

    <billroberts> BartvanLeeuwen: need enough people to start
    implementing the extra column in WFS

    <billroberts> eparsons: could propose this to OGC for the WFS
    standard (or a profile for WFS)

    <billroberts> BartvanLeeuwen: could probably avoid changing the
    WFS spec by using a profile

    <billroberts> jtandy: if phila were here, he'd remind us that
    BPs should be durable

    <billroberts> jtandy: could be more than one way to achieve
    something (to reflect changing fashions and practices) while
    still following the underlying, persistent BP

    <billroberts> eparsons: but make document usable by
    practitioners so not loads of different choices

    <billroberts> frans: WFS is not hte only kind of spatial data
    service we might have to consider

    <billroberts> jtandy: so, emergency response looks good for a
    common narrative through many examples in BP doc

    <billroberts> jtandy: how best to structure doc to make it easy
    to add value. How can we help spatial data publishers to add
    value without having to do very complicated things. What are
    the first/easiest things?

    <billroberts> jtandy: step 1 might be: get people to use HTTP
    URIs in their data

    <billroberts> jtandy: look for things that are profound but
    don't take much effort

    <billroberts> eparsons: different approaches might be
    appropriate for (a) 'green field' data publisher starting from
    nothing or (b) someone with a well-established set up that
    needs modification

    <billroberts> frans: examples could start simple (tweet about a
    fire) but bring in lots of detail later

    <billroberts> BartvanLeeuwen: flooding might be better example
    than fire for some BPs

    <billroberts> eparsons: if you didn't have GIS adn WFS
    'baggage' where would you start

    <billroberts> BartvanLeeuwen: good question, but people always
    want to see stuff on a map so GIS may be a good place to start

    <billroberts> eparsons: could just have an HTML page per record
    - simple, discoverable. May not need fancy GIS functionality

    <billroberts> eparsons: if I haven't got a GIS, do I need one?
    (for simple examples)

    <billroberts> BartvanLeeuwen: in a flood warning, someone wants
    to know where to go to a safe place - doesn't want to start a
    GIS to get that

    <billroberts> roblemmens: time also relevant

    <billroberts> stanislav: in a complex emergency situation,
    improtant to have access to all relevant data in one place

    <billroberts> eparsons: emergency services 99.9% likely to have
    a GIS infrastructure

    <billroberts> ChrisLittle: these organisations may be in their
    own data silo but probably shouldn't be. Better to also be
    looking at eg social media and other external data sources to
    get whole picture

    <billroberts> eparsons: eg need to find all Starbucks stores
    (say) in response to a potential threat. Starbucks probably
    have a GIS but it's not accessible quickly to emergency
    services, whereas their store locator web page probably is
    accessible

    <billroberts> roblemmens: emergency services not the only
    users, also perhaps reporters/journalists

    <billroberts> eparsons: so we could recommend to companies to
    publish machine readable store locator info on their websites
    (whether or not they also have a GIS)

    <billroberts> jtandy: BBC uses linked data for underlying data
    infrastructure eg for sporting events. Could potentially be
    combined with other emergency response data

    <billroberts> BartvanLeeuwen: even if you can see a GIS you may
    not have enough info to interpret correctly. (eg opaque short
    codes for layers)

    <billroberts> BartvanLeeuwen: also multilingual issues
    sometimes - eg between Germany and the Netherlands in river
    flooding situations

    <billroberts> eparsons: so let's work with our current list of
    BPs and see if we need to restructure to allow us to use
    flooding as a narrative

    <billroberts> jtandy: also useful as a way to bring in Coverage
    data

    <billroberts> jtandy: as remote sensing very useful in flood
    situations

    <billroberts> eparsons: should also include fire based examples
    - Australian bush fires also brings some broader interest

    <billroberts> BartvanLeeuwen: flooding tends to be more
    interdisciplinary than fires,hence more interesting data
    exchange problems

    <billroberts> jtandy: what about examples of existing 'in the
    wild' best practices

    <billroberts> eparsons: should go through BPs and ask: who has
    a good example?

    <billroberts> jtandy: if you don't volunteer something, we'll
    have to get our dentist's pliers out

    <billroberts> jtandy: anyone got prepared examples relevant to
    specific BPs?

    <billroberts> jtandy: who has done their homework?

    <billroberts> BartvanLeeuwen: BP22. DBpedia uses Geonames

    <LarsG> BP 22:
    [39]http://w3c.github.io/sdw/bp/#link-to-auth-identifiers


      [39] http://w3c.github.io/sdw/bp/#link-to-auth-identifiers


    <billroberts> ClementsPortele: (audio hard to follow but...) he
    is using Geonovum testbed. Experiment to supplement existing
    WFS infrastrucure to be more webby

    <billroberts> ClemensPortele: has x-ref'd that with the BPs.

    <billroberts> ClemensPortele: offers to share more detailed
    information about htat, or could present during the meeting if
    required

    <billroberts> eparsons: please send a link to online info

    <billroberts> jtandy: (1) sounds great, thanks (2) could you
    show it on webex, or is that practically difficult

    <billroberts> ClemensPortele: yes, could show on webex

    <billroberts> webex being screen transferred to
    ClemensPortele...

    <billroberts> [ClemensPortele presents from his screen]

    <billroberts> ClemensPortele: data from the Netherlands,
    including kadaster

    <billroberts> ClemensPortele: based on existing SDI in NL

    <billroberts> ClemensPortele: make a new 'layer' to access the
    data in a more webby way

    <billroberts> ClemensPortele: using schema.org, using HTML and
    JSON-LD, supporting content negotiation, allow all data to be
    indexed

    <billroberts> ClemensPortele: [shows list of BPs - which have
    been implemented?]

    <billroberts> ClemensPortele is currently writing this up,
    report available around end of month and will share it when
    ready, so we can read more about which aspects of BPs have been
    implemented

    <billroberts> ClemensPortele: thinking about providing a
    Swagger description for the API, but not sure when taht will be
    done

    <billroberts> ClemensPortele: not implementable BPs: reusing
    authoritative identifiers...

    <billroberts> and other not implementable (for this work) BPs
    listed

    <billroberts> ClemensPortele: experience of trying to x-ref to
    BPs has revealed some cases where revising the BPs might make
    them easy to work with or test

    <billroberts> ClemensPortele: eg need metadata in both DCAT and
    schema.org - content negotiation not sufficient to distinguish
    these two

    <billroberts> ClemensPortele: struggling to implement some best
    practices.

    <billroberts> ClemensPortele: Agricultural data example. Shows
    links from RDF data to the WFS resources

    <billroberts> eparsons: thanks Clemens for v useful
    presentation

    <billroberts> jtandy: great piece of work, thanks. Thanks also
    to Geonovum for the testbed. As well as stuff in the BP doc,
    can we also have interactive resources, such as Clemens'
    demonstrated systems?

    <billroberts> frans: can W3C host persistent example services.
    Question for phila when he's back

    <billroberts> eparsons: to be pragmatic, treat persistent
    testbed as a nice to have. Often practical difficulties about
    ongoing funding for hosting

    <billroberts> ClemensPortele will post a link in IRC

    <billroberts> ChrisLittle: Clemens, how confident are you of
    categorisation of BPs as implementable/not-implementable. Was
    it difficult to decide?

    <billroberts> ClemensPortele: some of those categorisations of
    BPs need some detail/qualification

    <billroberts> jtandy: useful to know if the BP is clear as a
    standalone text. Asks Clemens for further insights as we go on

    <billroberts> eparsons: next item, scoping issues

    <Zakim> rachel, you wanted to mention examples of named epochs
    and events for BP1

    <billroberts> rachel: has done some work on BP1, names of
    epochs etc

    <billroberts> rachel: Linked Open Data Finland has useful
    examples of referring to events and places

    <rachel> example

    <scribe> scribe: BartvanLeeuwen

    <scribe> scribenick: BartvanLeeuwen

    <rachel> [40]http://www.ldf.fi/ Linked Open Data Finland

      [40] http://www.ldf.fi/


    <rachel> e.g. Event: Atrocities in Namur
    [41]http://ldf.fi/ww1lod/d75dce08


      [41] http://ldf.fi/ww1lod/d75dce08


    <rachel> Geological epoch
    [42]http://resource.geosciml.org/classifier/ics/ischart/Jurassi

    c

      [42] http://resource.geosciml.org/classifier/ics/ischart/Jurassic


    <rachel> Fosse Way Roman road
    [43]http://pleiades.stoa.org/places/656280677


      [43] http://pleiades.stoa.org/places/656280677


    <ClemensPortele> Link to my slides:
    [44]https://github.com/geo4web-testbed/topic4-general/blob/mast

    er/geo4web-topic4-sdwbp-20160208.pdf

      [44] 
https://github.com/geo4web-testbed/topic4-general/blob/master/geo4web-topic4-sdwbp-20160208.pdf


    <rachel> Namur [45]http://vocab.getty.edu/tgn/7007960


      [45] http://vocab.getty.edu/tgn/7007960


    <rachel> Getty Iconography Authority [46]http://vocab.getty.edu


      [46] http://vocab.getty.edu/


    <rachel> Getty Iconography Authority (cultural objects
    including historical events) a module of Cultural Objects Name
    Authority (CONA)

    <LarsG> scribe: Lars

    <LarsG> scribenick: LarsG

    Stanislav: presents a spatio-temporal content explorer
    ... can navigate from a class of objects and show instances on
    the map
    ... (all in one screen)
    ... result filtering features
    ... particularly limiting the number of results (for SPARQL
    endpoint reasons)
    ... then navigate through relations (properties) and then
    filter again (e. g addressable objects) and connect to house
    numbers
    ... backend is GeoSparql
    ... can also filter on time

    phila: Do you filter the subset or all the data on the same
    time?

    Stanislav: it's a subset already
    ... Navigating data (e. g. buildings) filtering by temporal
    extent
    ... showing a timeline when buildiings were erected

    ChrisLittle: highlights how important it is to tell what
    calendar was used

    roblemmens: This example shows the value of linking data

    eparsons: This way linked data can add back to geospatial

    phila: billroberts does this kind of visualisation for a living
    hiding triples from the end users

    Stanislav: in geospatial the human interfaces are extra helpful
    (easier to show it on a map than to explain)
    ... uses Parliament (only triple store that supports full
    geosparql)

    roblemmens: usability aspects are still to be solved
    ... UI hard to grasp for inexperienced users

    jtandy: With geosparql you are constrained to geosparql
    vocabulary

    Stanislav: Yes, we use WKT for geometries

    ChrisLittle: particular case of presenting spatio-temporal data

    aharth: has played with web data and one important point is how
    to visualise people on a map
    ... datasets differ on how they attach lat/long to objects.
    DBPedia attaches directly to the location, others do it
    differently
    ... sometimes you have to go through the attached geometry

    phila: foaf:Person is subclass of wgs84:SpatialObject

    kerry: how would jtandy want people to contribute to the BP?
    One wiki page per BP?

    jtandy: hasn't thought about that yet
    ... but acknowledges the need for a place to share content.
    Wiki page sounds good

    eparsons: it needs to be directed. Start with empty page and
    then fill iin during the calls.

    Linda: One BP per time?

    eparsons: yes. Perhaps a separate telecon if necessary

    kerry: Prepare a wiki page _before_ the meeting would be ideal

    frans: one page per BP or one per example?

    <rachel> +q

    frans: and link that to the BPs

    jtandy: better to start with one big page

    rachel: +1 to jtandy

    eparsons: should suit the needs of the editors
    ... that would naturally work its way through

Scoping

    jtandy: much in BP is about exposing data through web services
    ... all questions were asked through the lense of exposing
    feature services
    ... but it's all appliable to other kinds of data, too
    ... so it might be out of scope but otoh it needs to be in the
    document for the geospatial community to understand that it's
    important

    eparsons: So are we OK with publishing some BPs that aren't
    particular to _geospatial_ data? eparsons is OK with that
    ... if we end up with recommendation à la "publish geospatial
    data the same way you'd publish other data" that is OK

    <AndreaPerego> +1

    frans: anxious we don't have time to deal with hard geospatial
    problems (CRS)
    ... is the point that we would want to point to BPs yet to
    write by other groups?

    jtandy: DWBP works on a different level, so they might not
    solve our problems

    phila: If it's not in DWBP now, it won't get there, so if SDW
    has needs, we must put it into our own document

    AndreaPerego: We must provide examples of how we want our BPs
    to be done, even if it overlaps with other BPs
    ... sometimes we just extend things (e. g. GeoDCAT as an
    extension to DCAT without disturbing existing infrastructure)
    ... it's about showing people how to get linkable data within
    their own infrastructure even if that means giving general
    advice

    Linda: ClemensPortele has commented on this

    ClemensPortele: comments were specifically on out-of-scope for
    _our_ implementation, not general comments

    <Zakim> phila, you wanted to talk about
    [47]https://www.w3.org/TR/dwbp/#StructuralMetadata


      [47] https://www.w3.org/TR/dwbp/#StructuralMetadata


    phila: points to DWBP example

    <phila> [48]Structured

      [48] https://www.w3.org/TR/dwbp/#StructuralMetadata


    phila: example talks about location (use of dcterms:description
    is incorrect)
    ... we need to give guidance

    frans: haven't seen anything about precision, significant
    digits etc. Worried we might have too much work to do and not
    have time to focus on geospatial
    ... we should focus on those.
    ... it's a matter of priorities

    eparsons: but we need to build on general foundations on how to
    publish data. What do we percieve to be missing from DWBP?

    frans: there are BPs out there not just described in DWBP
    ... e. g. web documents on how to publish linked data, mint
    URIs etc. Probably also use of significant digits. We need to
    find those.

    jtandy: many haven't read common practice because it's not
    particularly about spatial data. We need to corral those and
    put all the BPs in one place
    ... even if this means stating well-known info about e. g APIs

    eparsons: +1. How much do we need to do before talking about
    spatial data?
    ... Is it a matter of work to do or just work we need to
    collect?
    ... Let's do what we have to do and then the missing pieces
    will emerge.
    ... be it minting URIs or whatever. Let's not panic yet.

    jtandy: other scoping question: sensor data
    ... many say this doesn't fit with spatial data

    <kerry> +q

    jtandy: How much do we want to pick up sensor data as a thing
    vs spatio-temporal aspects of sensor data?

    kerry: doesn't have an opinion. SSN ontology is important but
    that's not a BP document and perhaps we don't need that (nor as
    a part of another BP doc)

    <jtandy> [49]http://w3c.github.io/sdw/bp/#describe-process


      [49] http://w3c.github.io/sdw/bp/#describe-process


    jtandy: BP 15 [50]http://w3c.github.io/sdw/bp/#describe-process

    is very specific, describing a data stream, but not specific to
    sensor data

      [50] http://w3c.github.io/sdw/bp/#describe-process


    eparsons: what is a sensor, someone with a twitter account
    (from telecon last week)
    ... essentially everything is a sensor

    kerry: BP 15 is also about provenance etc so it's not sensor
    data specific
    ... crowd sourced data is similar

    jtandy: is nervous about scope re. consuming sensor data

    kerry: perhaps summarise it all in a single BP ("use ssn
    ontology for sensor data")

    eparsons: perhaps we shouldn't make BPs for sensors and time
    until we have the ontologies to describe them

    kerry: those ontologies should make it into the BP doc

    phila: The BPs came out of use cases and if we strip them out
    of BP we're ignoring needs coming from UCs.
    ... Those are needs from geospatial and web community

    jtandy: many UCs came as input from SSN deliverable, not BP

    ChrisLittle: The ontologies sit on microformats and feed into
    the ontologies. We cannot do one without the other

    eparsons: We have problems both in temporal aspects and the
    fact that much will come from sensors
    ... We need to extract the problems from possible solutions
    (such as SSN and time ontologies)
    ... We can say that there are problems with particular
    technologies without having to provide a solution to them
    ... perhaps we need to rephrase some BPs not to cite other
    deliverables

    jtandy: In emergency response there is much sensor data
    ... so instead of saying exactly how it works we just use them
    as examples (e. g. the location of a smoke detector) and from
    there convey the connection to the SSN ontology

    frans: it's good to link between the deliverables

    BartvanLeeuwen: No problem to sneak sensors into the emergency
    rescue narrative is not a problem

    billroberts: and sensors can move around, tooo

    eparsons: time and ssn are both valuable but they might not be
    BP (yet)
    ... if it's not mature we cannot really say it's a best
    practice

    phila: BP is about "providing sensor data in a structured way;
    have a look at ..."

    jtandy: (recapping)
    ... use web services to publish spatial data. This was an
    inhibitor.
    ... Much future data will be sensor data, but we'll not say how
    to publish this data unless it's particular to spatial (e. g.
    an air quality monitor on a bus)
    ... or how to deal with streaming data. This is appropriate to
    sensor but not particular

    <rachel> [river gauges as sensor input to flooding emergency
    response [51]http://www.gaugemap.co.uk/ using
    [52]http://www.shoothill.com/environment-agency-liveapi/]

      [51] http://www.gaugemap.co.uk/

      [52] http://www.shoothill.com/environment-agency-liveapi/]

    jtandy: Wild fire observations can come from humans. This is
    more about semi-structured information than about sensors

    eparsons: "If you want to deep dive, have a look at ..."
    ... and point people to upcoming work (including CRS,
    non-Gregorian calendars etc.)
    ... but we have to provide some pointers on how not to make
    certain mistakes

    frans: Important question is how to put geometry on the web.
    This is not only sensors but everywhere
    ... BP right now is to do it in a fashion that fits your need,
    so we might need to develop our own ontology. This we need to
    address

    eparsons: do you talk about a simple features ontology or
    something else?

    frans: not only for buildings or geographical data, but also
    microscopes and geometry in general (i. e. on the web)

    jtandy: What's wrong with the current five ways?

    frans: the problem is that there are five and those are much
    more about geographical than about geometry. There are too many
    ways to express time and space
    ... We need one way to rule them all

    AndreaPerego_: there are reasons that there are more than one
    ... applications are built to consume different kinds of data
    ... services should ideally serve data in different ways (GML,
    WKT, ...)

    <phila> [53]The Core location Vocabulary

      [53] https://www.w3.org/ns/locn


    AndreaPerego_: we have recommendation on how to represent
    geometries (GML, WKT, GeoJSON). It depends on the use case
    which one you pick.

    <phila> [54]XKCD 927, the one about having too many standards

      [54] http://xkcd.com/927/


    jtandy: sometimes it's too complicated to do simple things in
    the "best" vocabulary

    frans: we shouldn't say it's impossible to come up with one
    single model. We should attempt to find an interoperable way.

    jtandy: Do you want a conceptual model (we've got one) or do
    you talk about implementations.
    ... Should we say "this is the only one we recommend"? That way
    we can alienate parts of the community

    aharth: There are differences in conceptual model. WGS84
    doesn't differentiate between thing and geometry. It would be
    nice to describe the differences between them and align that
    with the web data model

    Linda: it would help people if we can order the existing models
    according to ease of implementation ("but if you want polygons,
    you must use X")

    AndreaPerego_: Like having a decision matrix

    phila: OGC is happy to do GeoSparql 1.1 if necessary
    ... it's not helpful to define a sixth vocabulary

    ClausStadler: there is a difference between how data providers
    work and how tool implementers work.

    billroberts: If we say there is only one way, we'll be ignored.
    Instead we should give advice on how to document our decisions
    (vocabulary, use of CRS) and how to convert between them.

    <Zakim> phila, you wanted to say the thing I forgot to say
    about addresses

    billroberts: If there are gaps we should close them

    phila: Addresses are important. vCard is well implemented and
    is not INSPIRE compliant. We should give advice on how to
    publish an address

    <billroberts> +1 to importance of addresses

    ChrisLittle: All this fits into precision and accuracy. Not
    only "where is the house" but also "which door". And how to do
    that transition

    <eparsons> thanks rachel !

    BartvanLeeuwen: We also need a remark on who we expect to
    consume our data. People often want to publish data because
    they have it but their customers don't have the tools to
    consume it
    ... e. g. no support of arcs in OpenLayers

    <BartvanLeeuwen> +1 to addresses

    frans: no consumer group would be happy with five or six ways
    to do the same thing since they will need to implement support
    for all of those
    ... that's too much if-then. They will want one spatial
    ontology
    ... we should try to make progress here

    eparsons: we can look at how to close gaps but shouldn't spend
    too much time

    frans: our extensions should be compatible with all existing (a
    sort of super-model)

    billroberts: much of data consumption is driven by existing
    tools. So often we need to publish using several
    formats/vocabularies

    jtandy: points to BP 7 where this topic is addressed

    frans: we should not start from geography but from mathematics
    when creating this ontology

    <aharth> scribenick: aharth

    <phila> scribe: aharth

    LarsG: our discussion relates to Clemens' point earlier: we
    need to be able to support different representations/schemas of
    the same thing
    ... there's an Internet draft in the works regarding
    Accept-Schema
    ... client and server can negotiate the schema used

    eparsons: how does it help if we talk about a very abstract
    geometry model first, leading to the final encoding

    frans: we need an abstract model that is powerful

    phila: how much effort would it be to come up with a table to
    help people make a decision regarding the vocabulary?

    frans: geosparql could be the model

    phila: most people might think of terms of addresses rather
    than geometries...

    <jtandy> [@lars: see RFC 6906 from Eric Wilde - The 'profile'
    Link Relation Type]

    frans: it would be helpful to converge to one vocabulary for
    spatial data

    phila: we could get spatial relations into the link registry

    billroberts: what are the most common use cases? addresses,
    geocoding, postcodes, points and polygons...
    ... but mostly polygons are not available
    ... then, especially in statistics, the next level of
    complexity is how polygons relate to each other
    ... there are many pragmatic problems around that are a big
    barrier

    frans: how do you put a geometry into a triple store?

    billroberts: some of the triple store technology is not
    advanced enough, use postgis, elasticsearch
    ... we would use more geosparql if there are implementations
    available

    frans: geometry is just a datatype like numbers, string

    aharth: i'd say a polygon is an object, rather than an image

    <ClausStadler> base64 encoding - webpack optimizes html pages
    by inlining all images like that

    ChrisLittle: numbers are not enough to encode geometries, need
    numbers + other data

    <ClausStadler> what i wanted to say is that binary data could
    be encoded using e.g. base64, so in a way it would be possible
    to support it in rdf

    billroberts: is it an object, is it a database-y type of thing?
    for most things we need both
    ... we are in a tricky situation where we need both

    jtandy: i'm reminded of discussions of the JSON-LD space...
    people were not really fans of RDF triples
    ... maybe there's a way to use a triple data model without
    requiring much of the semantic web machinery

    ChrisLittle: maybe link to an object, dismantling it does not
    necessarily have to be done using rdf tools

    frans: there are functions in geosparql to do that

    eparsons: we carry on discussing this lateron, let's come back
    to that
    ... next topic is the engagement with the DWBP

    phila: presents the current version of the DWBP document
    ... the document has many navigational aids: challenges,
    benefits, used to classify the best practices
    ... only one best practice is open (related to APIs)
    ... now the thing left to do is to create examples and tests
    ... the DWBP document will be a Recommendation
    ... which means for each of the best practices there need to be
    two organisations that have made the same recommendation
    ... in other words, find two independent implementations of
    each best practice
    ... charter of DWBP runs out in july
    ... the goal is to provide a running example with actually
    testable data
    ... there's currently much effort to finalise the DWBP bp
    document

    jtandy: in preparation for next week's call, what version of
    the document should we read?

    phila: i would read the editor's draft
    ... for next week, we're flagging places where things related
    to spatial can be improved

    frans: do they have public comments?

    phila: we've got some comments, but would like to have more

    <phila> [55]data on the Web Best Practices Editors' Draft

      [55] http://w3c.github.io/dwbp/bp.html


    jtandy: please, read through the document and find gaps
    relative to our work

    AndreaPerego: there are other deliverables (a couple of
    vocabularies) that might be worth looking at

    <phila> [56]Data Quality Vocabulary

      [56] https://www.w3.org/TR/vocab-dqv


    <phila> [57]Dataset usage

      [57] https://www.w3.org/TR/vocab-duv


    phila: permissions and obligations is another topic that's
    coming up

    <Zakim> AndreaPerego, you wanted to ask if DAQ / DUV will
    address also data granularity

    phila: data shapes (SHACL) is a "schema"-language, there's
    recent progress there

    AndreaPerego: what about granularity in the vocabs? might be
    relevant to us, for example the way to model spatial
    resolutions

    phila: dcterms:conformsTo is a start
    ... candidate rec for the two vocabularies is targeted for
    march

    jtandy: I wonder if the two vocabs provide examplars for how we
    should publish vocabs

    phila: yes. a class diagram is usually the first thing people
    look at
    ... it's the same pattern that the other ontologies (DCAT...)
    use

    jtandy: look to see if they handle location correctly, identify
    whether they cover our issues (otherwise we need to get the
    issues into our document)
    ... best practice: we have a room of implementation community
    with us on wednesday
    ... what are the questions we want to ask them?

    <eparsons> action jtandy to email public list with homework re
    DWBP call next week

    <trackbot> Created ACTION-138 - Email public list with homework
    re dwbp call next week [on Jeremy Tandy - due 2016-02-15].

    jtandy: suggestions: tool chains/software architecture
    ... e.g., triplestores with sparql, elasticsearch, or something
    in between, HTML in vi...
    ... is that a useful question to ask?
    ... for the data publishing folks: what kind of spatial data
    are you trying to publish? geometries vs. points?
    ... for the data consumers: what is preventing you using
    spatial data in applications and decision making?

    frans: i wonder what we do with the answers

    jtandy: that might help us prioritise in which order to put
    different approaches/formats into the bp document
    ... which formats do you typically publish data in?

    frans: ask for what people like to do, but find impossible or
    difficult to do now

    jtandy: format one is interesting, because it gives a hint
    about the currently used toolchain
    ... provide examples from the real world
    ... how should we structure the bp doc for readers with short
    attention span

    eparsons: we should use the event for sense-checking, not
    gathering new requirements

    BartvanLeeuwen: maybe explain how we end up at the WG

    jtandy: yes we will do that

    BartvanLeeuwen: careful to not raise expectations we cannot
    fulfil

    jtandy: "what do you want from this" would be another question

    Linda: if people asked the public draft, are we going to ask
    for specific questions?

    jtandy: will do
    ... our sensor data discussion might be worth mentioning

    Linda: we have 1 hour 45 minutes, keep time in mind

    eparsons: we're about done for the day

    Linda: tomorrow we are at a different location, house number 2,
    in the meeting center, lunch and afternoon session at the same
    place as today

    eparsons: thanks and see you

Summary of Action Items

    [NEW] ACTION: frans to clarify use case requring
    differentiation between real world and representation
    identifers, during Wendesday's workshop [recorded in
    [58]http://www.w3.org/2016/02/08-sdw-minutes.html#action01]

      [58] http://www.w3.org/2016/02/08-sdw-minutes.html#action01


Summary of Resolutions

     1. [59]approve sapporo f2f minutes
     2. [60]approve sapporo f2f minutes day 2

    [End of minutes]
      __________________________________________________________

Received on Monday, 8 February 2016 22:56:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:20 UTC