W3C home > Mailing lists > Public > public-sdw-wg@w3.org > March 2017

Summary of Best Practice sub-group discussions from Day 1 of Delft face-to-face

From: Jeremy Tandy <jeremy.tandy@gmail.com>
Date: Mon, 20 Mar 2017 22:40:04 +0000
Message-ID: <CADtUq_2RmjAbww7Rj+r-4Dsi2HXfnp6aGq84h71BFbqPAxyT9Q@mail.gmail.com>
To: SDW WG Public List <public-sdw-wg@w3.org>
Hi. I think we had good session today and are well prepared for our "final"
sprint.

We voted to release another WD: a huge thanks to the contributors! As we
said during the meeting today, Linda & I have a couple of broken things to
fix before publication. The earliest we can do that will be in 8-days time.

So- if you're quick off the mark in wanting to do you actions, please can
you continue to work in a temporary branch and don't submit any Pull
Requests to gh-pages until we've officially published. If you do, we'll
just reject them :-)

Also, for reference, I attach my notes from today's discussion; I think
that I captured some bits that may not have been in the minutes -
particularly the sprint plan (not sure - haven't checked).

All the best & enjoy the rest of the SDW and/or OGC TC meeting(s).

Jeremy

-----------

*Spatial data on the Web: Delft face-to-face meeting*

(20-March-2017)

*BP sub-group*

(to complement the official minutes:
https://www.w3.org/2017/03/20-sdw-minutes.html)


*samePlaceAs discussion*:

schema:samePlaceAs?

… alternative options are ov:similarTo, or the skos:closeMatch /
skos:exactMatch

… avoid creating something new? - *after all, we’re creating best practice
based on what people do rather than creating new ideas!*

…

[roba (by email)] “you would be better off using skos:closeMatch,
skos:exactMatch etc. … also allows you to use skos:broader / narrower with
transitive versions, and doesn’t preclude using a more nuanced geographical
relationship that is a subProperty of SKOS relationships … keeps it within
the W3C canon, consistent with other OGC usages of SKOS, and is about
_relationships between concepts_ … on the other hand the semantics is
explicitly about geographic relationship of related but distinct things,
then i would suggest using GeoSPARQL or fall back to general advice about
re-use of vocabularies”

[jano (by email)] +1



   - [Jeremy] notices a spelling mistake in the proposed definition:
   “Values expected *o* be one of these types: Place
   <http://schema.org/Place>“
   - [Josh] notes that there are two types of ambiguity here
      1. ambiguity of _concept_
      2. ambiguity of _location_ (or _place_)
   - … we want to describe similarity of location (or place) - not
   similarity of concept
   - #2 is our focus - but we should talk about #1 as a separate concern
   - [kerry] are Byzantium and Istanbul the same Place? “Yes- if you want
   them to be”
   - … samePlaceAs is not a symmetric property
   - [byron] doesn’t like “Place” - there is no strict location element (he
   refers to the example of a hotel that was moved across the street but still
   considered the same place)
   - … perhaps we need a different concept? - in addition to the social /
   perceived relation of samePlaceAs
   - … e.g. similarLocationTo - which [Josh] clarifies to “colocatedWith”
   e.g. the ‘meeting place’ is <colocatedWith> the ‘south corner of the part’
   - … Eddystone Lighthouse provides a good example; there have been 4
   buildings on the site over the years that could all be considered to be
   “colocated”
   - colocatedWith is for use when there is not enough information
   available to compute a topological assessment (e.g. no geometries)
   - we have evidence of a requirement - but no consistent practice: so we
   make a proposal about a RECOMMENDED practice (rather than best practice
   based on evidence)
   - [roba] polymorphism is your friend- you can have multiple relations
   - … the best practice here seems to be “use the most precise [spatial]
   relationship you can (e.g. assert the computed topological relationship,
   such as geosparql:sfEquals, if there are geometries available to compute
   it) - and add the more generalised used by your community if they makes
   sense”
   - [ed] likes “Place” - it has a useful vagueness of location and extent;
   this is a valuable property - we often will want to express the
   _perception_ of equality without the underpinning geometry
   - … samePlaceAs and colocatedWith are _different_ properties - one is
   not better than the other, they’re just different
   - [josh] notes that “keys on the counter top” is, according to the
   SCHEMA-ORG definition a “Place” (it has spatial extent) - this conflates
   “Place” and “SpatialThing”; it is missing the nuanced semantics of “Place”
   - … “Place” is a piece of geography or topography that people NAME
   (toponyms) - where there is sufficient human interest to name it
   - … thankfully, not every coordinate position on the Earth is a Place!
   - [jeremy] do all places have spatial extent? e.g. if you take the
   definition of home from a popular song “wherever I lay my hat - that’s my
   home […]”
   - [byron] suggests that Place has an agreed spatial extent … [agreed by
   at least two collaborators]
   - … that people name
   - … this may move
   - [Linda] suggests proposing a refinement of the definition of
   schema:Place - to exclude things like “my keys”
   - [jeremy] what domain and range for…
      1. samePlaceAs: [the refined definition of] schema:Place
      2. colocatedWith: schema:Thing
   - [jeremy] also see geonames:nearby as another qualitative relationship
   that could be used alongside “colocatedWith”
   - [josh] we want to assert spatial relations between [spatial things]
   but we can only test those relations between geometries … property chaining
   may address this in the future - but for now we recommend two properties
   (samePlaceAs and colocatedWith) as shortcuts
   - [roba] use strong examples to should how the properties _should_ be
   used, but
   - … explicitly call out where _not_ to use the properties
   - … we don’t specify exactly what “colocatedWith” means - applications
   may need to refine (narrow) the semantics to meet their needs (e.g. to
   specify a maximum distance that is used to assert the colocation)
   - [andrea] can we say that “two events are colocated”? e.g. this SDW
   face-to-face meeting is “colocatedWith” the OGC TC meeting
   - … could people misuse this?
   - [jeremy] in this case, suggest that people use the <schema:location>
   property (of schema:Event) to refer to the “Faculty of Architecture,
   Technical University of Delft” for both events
   - … this appear to be an example that we can use to illustrate how _not_
   to use the property - one where the common language patterns don’t always
   work


*Introducing the changes made during Feb/Mar sprint*:

   - [BP1: Include spatial metadata in dataset metadata]
      - [jeremy] still needs some work to reflect the conversation in London
      <https://www.w3.org/2015/spatial/wiki/BP1_discussion_notes_from_LondonF2F>;
      e.g. DCAT as a placeholder, if you’ve got rich spatial metadata
then re-use
      that in a Web friendly way etc.
      - … ref. BP4 “make it indexable by search engines”
      - … perhaps we should include _METADATA_ into BP4 alongside _DATA_?
      - [linda] BP4 already mentions dataset metadata
      - [jeremy] Dataset metadata as LANDING PAGE (note: WxS
      GetCapabilities acts like a Landing Page)
      - KEEP BP1 AS IS; TALK ABOUT ACCESS and INDEXING ELSEWHERE … POINTER
      TO REALTE BP1 and BP4
   - [BP3: Choose the coordinate reference system to suit your user’s
   applications]
      - [byron] asks for the title to be _plural_ “coordinate reference
      systems”
      - … and use augmented reality as an additional example of where high
      precision is required - alongside defence etc.
   - [BP4: Make you spatial data indexable by search engines]
      - see comment above from BP1 discussion
      - [lars] notes that sitemaps statement is incorrect
      - [clemens] to draft a change; [lars] to review
   - [BP5: Describe the positional accuracy of spatial data]
      - no updates in this sprint; needs a review
   - [BP6: Describe properties that change over time]
      - no comments
   - [BP7: Use globally unique persistent HTTP URIs for spatial things]
      - no update in this sprint
   - [BP8: Provide geometries on the Web in a usable way]
      - *work to continue in next sprint (Andrea listed the additions in
      the green note at the end of the BP)*
      - [josh] suggests that the BP8 should be refactored into 2-parts …
      - A/ general guidance about geometries:
         1. geometries should be Web-addressable - e.g. so a request for
         [information about] a spatial thing does not need to have a
potentially
         huge geometry object embedded in the response (you can ask for it
         separately) - and this enables content-negotiation to be used when
         requesting the geometry itself
            - note: data.geohive.ie uses blank nodes for geometry; I think
            we’re agreeing that this _is not_ best practice
         2. if a geometry has a specific role (e.g. centroid, centre-line,
         bounding-box), that geometry should be referenced from the
spatial thing
         using a link relation type that conveys the semantics of that role
         3. geometries should be encoded in a useful way - e.g. selecting
         the right format (or formats) for serialisation; including
details of how
         to compress / simplify geometry where appropriate for the application

      - B/ guidance about providing multiple geometries
      - [phila] please change “intended uses” to “likely uses”
         1. … check elsewhere too
      - [phila] where you mention content negotiation by profile, please
      amend to say this is not _currently_ possible (ref. the
anticipated outcome
      of the Data Exchange Working Group) « this is one of the “open issues” to
      be put into the “Conclusions”
   - [BP9: Describe relative positioning]
      - big update
      - [jeremy] needs so data-snippets for examples (people learn by rôte)
      - [josh] to add data-snippets to examples 22, 23 and 24
   - [BP10: Encoding spatial data]
      - *work to continue in next sprint (Bill & Jeremy have a list of
      additions to work though)*
      - [byron] not sure the 4 categories of data publication fit; what
      about data journalism?
      - [jeremy] thinks that this is covered by the two middle categories
      - [byron] is content with that; no change required
      - [kerry] asks that we check the language used in order to be aligned
      with [phila]’s earlier comment; “likely to use” vs. “intended use” or
      “target use”
         1. EDITORIAL TASK to check consistency of language
      - [clemens] on the for categories, SDI is not the same; it’s not an
      application - it’s infrastructure (and use can use this for web mapping,
      data integration etc. albeit not always so easily)
      - … also “spatial analysis” is a missing application
      - … suggest replacing SDI with “spatial analysis” (e.g. what you
      would use a GIS for)
      - [jeremy] broadens proposal to “spatial analysis and data management”
      - [bill] to update accordingly
   - [BP11: Expose spatial data through 'convenience APIs']
      - no comments
   - [BP14: Publish links between spatial things and related resources]
      - *needs to be refactored into 2 best practices (general linking &
      link relation types) and an open issue for the Conclusions* ([jeremy]
      can do this; see discussion below on evaluation of possible approaches -
      ref VoID)
      - [linda] general linking is not a spatial concern; does it fit as
      one of our best practices?
      - [jeremy] but DWBP says nothing about this - so we need to
      - … for next release try the general linking content as a BP; if that
      doesn’t ‘flow’, move to appendix
      - … as per BP8, where you mention content negotiation by profile,
      please amend to say this is not _currently_ possible (ref. the
anticipated
      outcome of the Data Exchange Working Group) « this is one of the “open
      issues” to be put into the “Conclusions”
   - [BP17: State how coordinate values are encoded]
      - [andrea] WKT [often] has specific coordinate order irrespective of
      the CRS statement (e.g. the PostGIS implementation)
      - … WKT is not implemented consistently
      - PROPOSAL: add a green note with a warning about this behaviour and
      advising readers to be aware … simple way to check the
implementation is to
      see if Amsterdam appears in the vicinity of Somalia!
      - [andrea] to draft the text
      - [byron] regarding the four possible approaches to implementation,
      #4 (specify CRS in dataset metadata) should always be done (see BP1) and
      may be used to complement one of the other approaches


*vote to release another WD*:


*NOTE: SECTION BREAKS ARE BROKEN- APPENDICES ARE NOW JUST NORMAL SECTIONS*
… need to investigate and fix before releasing WD

*NOTE: “CROSS REFERENCE OF USE CASE REQUIREMENTS AGAINST BEST PRACTICES” IS
BROKEN* … this uses JavaScript to construct the table … need to investigate
and fix before releasing WD

*NOTE: NEED TO UPDATE THE “CHANGES SINCE LAST RELEASE” AND “SOTD” SECTIONS*
… before releasing WD


APPROVED!


>>>> Linda & Jeremy to discuss on Tue 28th about these fixes & then notify
W3C for publication.


*Evaluating which “possible approaches to implementation” are genuinely
best practice*:

   - Document OK except for …
   - “Link discovery” recommendations in BP14
      - [roba] SIRF was a “research activity” which concluded that VoID
      wasn’t broken; the experience is that the VoID vocab has utility in
      resolving the challenge of making Links more visible
      - … VoID is published as a W3C resource
      - … the Best Practice here seems to be “reusing existing [standard]
      vocabularies” (ref. [DWBP])
   - Both SIRF and Triple Pattern Fragments use VoID (but not clear how
   much TPF does so)
   - The 3 approaches listed aren’t mutually exclusive
      - use search engines
      - publish with ad-hoc services
      - re-use [standard] vocabularies
   - [Linda] offers to search for more examples; e.g. with Kadaster
   - [Linda] this is not really a spatial issue - and therefore shouldn’t
   be a focus of ours
   - *PROPOSAL: move that section of BP14 to the “Conclusions” section as
   an “open issue”*



   - also note that the samePlaceAs / colocatedWith should also be consider
   a ‘recommend practice’ rather than one based on evidence of adoption


*Document restructuring*:

Current BP list (incl. the refactoring of BP8 and BP14):

   1. [BP1: Include spatial metadata in dataset metadata]
   2. [BP3: Choose the coordinate reference system to suit your user’s
   applications]
   3. [BP4: Make you spatial data indexable by search engines]
   4. [BP5: Describe the positional accuracy of spatial data]
   5. [BP6: Describe properties that change over time]
   6. [BP7: Use globally unique persistent HTTP URIs for spatial things]
   7. [BP8: Provide geometries on the Web in a usable way]
      1. [BP8a: geometry representations]
      2. [BP8b: multiple geometries]
   8. [BP9: Describe relative positioning]
   9. [BP10: Encoding spatial data]
   10. [BP11: Expose spatial data through 'convenience APIs']
   11. [BP14: Publish links between spatial things and related resources]
      1. [BP14a: general linking]
      2. [BP14b: relations]
   12. [BP17: State how coordinate values are encoded]


14 best practices in all.



   - [jeremy] suggests restructuring based around the sequential order of
   the [spatial] data publishing process - the workflow:
      1. URIs
      2. What spatial data represents (CRS [BP3], positional accuracy,
      etc.) … all the “Describe” BPs?
      3. Links
      4. Encoding data ([BP10] & the “4 main scenarios”, [BP17] expressing
      CRS, [BP8] web-friendly geometry)
      5. Indexable by search engines [or after “encoding data”?]
      6. Data access (download etc. from [DWBP], [BP11] convenience APIs)
      7. Dataset & Distribution metadata
   - …(this would match the flow in section 11 “How to use”
   - [ed] suggests possibly ordering based on impact?
   - [jeremy] ticks through the list of BPs to see which are “more
   important”
   - … high importance: 3, 4, 7, 8, 10, 11, 14 & 17
   - … lower importance (but still useful!): 1, 5, 6 & 9
   - [linda] wants to try & see based on further consideration of reader’s
   needs; and report back
   - … will target one of the plenary calls for the proposal
   - [ed] suggests that we draw reader’s attention to what they need to do
   differently; should we order based on impact - or workflow? … whichever, we
   should complement with a summary statement (the “elevator pitch”) that says
   “these are where we are recommending a big change compared to current
   widespread practices”
   - [jeremy] this might fit in the introductory material; perhaps as an
   intro to section 4. Best Practices Summary



   - [jeremy] asks what to do about the file-format list in Appendix A and
   the vocab list in section 12.5
   - … how useful is the vocabulary list?
   - … should we just be saying “re-use [standard] vocabularies” as per
   DWBP? … which says to use LOV etc to find vocabularies?
   - … we already reference lots of vocabularies (and file formats) in
   examples
   - >> we reviewed each vocabulary and format as a group and created a
   slimmed down list; criteria for vocabularies excluded anything that is
   defined (& used) by only a single  organisation (e.g. Ordnance Survey’s
   geometry vocab); for file formats, we only chose _open_ formats - so
   Shapefile and MBTiles were excluded
   - [jeremy] asks to include HTML (with embedded structured data) as one
   of the formats! (to support the simple spatial data publication case!) and
   RDF serialisations e.g. JSON-LD (to support the data integration case,
   amongst others - providing simple formats in which the vocabularies can be
   used!)
   - [andrea] had already started writing a couple of lines of description
   for each vocabulary; he will continue to work through the slimmed down list
   - now including the formats too!
   - [jeremy] this should be the basis of a new Appendix


*open issues*:

   - [clemens] offers to amend BP11 to refer to spatial operators
   - we RESOLVE to defer publication of geosparql simple features relations
   to the IANA Link Relation Types registry
   - [clemens] and [lars] agreed to resolve the sitemaps issue offline
   - based on feedback from the community we decide to accept the current
   text in BP7 about use of “indirect identifiers” and close ISSUE 208;
   [linda] to remove the issue text from the document and close the issue



*Next sprint*:

   - update Glossary (still lots of yellow-highlight markup) (Peter Parslow)
   - update Acknowledgements - possibly add “Contributors” section (with
   names based on those who’ve committed changes in GitHub) at top straight
   after “Editors” (Editors)
   - merge slimmed-down lists from [APPENDIX A] (common formats) and intro
   material for [12.5 Spatial Data Vocabularies] (list of common vocabularies)
   into a new Appendix; “a couple of lines per entry” … try to map onto the
   four categories of spatial data publication (spatial analysis & spatial
   data management; data integration; web applications; simple Web
   publication) (Andrea to lead - with help from Bill [& anyone else?])
   - update “How to use” section (Jeremy)
   - updates to
      - BP3: minor edits (Jeremy)
      - BP4: metadata; ref. BP1 discussion) (Jeremy) and minor edits re
      sitemaps (Clemens; Lars to review)
      - BP5: review (Peter Parslow)
      - BP7: remove ISSUE 208 and close it (Linda)
      - BP8: ref email dialogue w. Andrea & Jeremy - listed in [green] note
      at end of BP; data.geohive.ie example - blank nodes for geometry; and
      get consistency with other BPs … and refactor into 2 best practices (a/
      general geometry publication; b/ multiple geometries) (Andrea)
      - BP9: data-snippets for examples 22, 23 and 24) (Josh)
      - BP10: ref. email dialogue w. Bill & Jeremy; “where you fit on the
      ‘spectrum’ of SDI to simple HTML page [e.g. publishing information about
      the village fête]” ; inc. Address and other mechanisms to
describe location
      (Bill)
      - BP11: add minor edit to reference spatial operators (Clemens)
      - BP14: refactor into 2 best practices + an “open issue” (Jeremy)
      - BP17: add a note about WKT coordinate order (Andrea) & state that
      approach #4 should always be done (ref BP1), combining with another
      approach when possible
   - conclusions and open issues (editors)
      - inc. “link discovery” (from BP14)
   - re-order / re-structure the BP document … and amend the introductory
   text sections for the re-ordered groups (Linda to come back with some
   proposals)
   - clarify intro to §12.5 - different ways to describe _position_ not
   location  etc. (Josh)
   - Add Peter Parslow’s proposed edits - recently received by email
   (Jeremy)
   - review the prioritised set of open issues in GitHub
   <https://github.com/w3c/sdw/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Abp>
   (focus on the important ones) (Linda to lead)
   - review outstanding public comments
   <https://www.w3.org/2015/spatial/wiki/Detailed_planning_BP_document#Review_public_comments>
   (Ed to lead)
   - “how to test” & “evidence” (e.g. cross-ref with UCR Requirements) …
   farm out to the BP authors :-)
   - benefits (Linda)
      - … need to add Appendix with the benefit description section too;
      same categories for consistency with DWBP - and include summary table and
      BP grouping graphic
      - … empty boxes are OK - it just means that Spatial Data on the Web
      doesn’t provide any extra guidance over DWBP


*and finally*:

   - [jeremy] suggests scheduling a 3-hour block teleconference to review
   (and close) all the remaining BP issues in GitHub
   - [linda] and [jeremy] to discuss Tuesday next week in their regular
   editor’s catch up
Received on Monday, 20 March 2017 22:40:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 20 March 2017 22:40:52 UTC