- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Mon, 20 Mar 2017 22:40:04 +0000
- To: SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CADtUq_2RmjAbww7Rj+r-4Dsi2HXfnp6aGq84h71BFbqPAxyT9Q@mail.gmail.com>
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