Re: My BP comments

> If this is the case than it seems to be an oversight on the part of the
UCR document. I think we should fix things there and make the two documents
consistent. Shall I create a UCR action for myself to check for missing
links from requirements to the BP deliverable in the UCR document? After
that, you should be able to reference only the BP requirements in the BP
document.

Let's aim to do that for the next WD releases.

Jeremy

On Wed, 13 Jan 2016 at 10:48 Frans Knibbe <frans.knibbe@geodan.nl> wrote:

> Hi Jeremy,
>
> Thank you for taking my comments seriously :-). I have one countercomment:
>
> 2016-01-12 17:44 GMT+01:00 Jeremy Tandy <jeremy.tandy@gmail.com>:
>
>> [snip]
>>
>
>>
>> > 16. Appendix C: Why are all UC requirements listed? Why not only the
>> BP requirements? That would make a more compact table.
>>
>> There were many requirements that were not specifically marked for the
>> BP- but turned out to be related ... so we captured those. Also, while we
>> are working on the BP, it's good to have this full list. Perhaps when we're
>> complete, it would make sense to truncate.
>>
>
> If this is the case than it seems to be an oversight on the part of the
> UCR document. I think we should fix things there and make the two documents
> consistent. Shall I create a UCR action for myself to check for missing
> links from requirements to the BP deliverable in the UCR document? After
> that, you should be able to reference only the BP requirements in the BP
> document.
>
> Greetings,
> Frans
>
>
>>
>> Thanks for all your efforts. Jeremy
>>
>> On Thu, 7 Jan 2016 at 12:30 Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>>
>>> Hello,
>>>
>>> Following are my comments, after reading the BP draft from top to bottom:
>>>
>>>
>>>    1. (already discussed in the teleconference) The introduction or
>>>    scope section could do with an explanation of how the document relates to
>>>    the description of the Best Practices deliverable in the charter,
>>>    especially the first and last bullet points.
>>>    2. I notice the word 'data' is taken as singular. That looks funny
>>>    to me, but I know there are differences of opinion in that respect. Do W3C
>>>    or OGC have a recommendation on whether to treat 'data' as a singular or
>>>    plural noun?
>>>    3. In paragraph 1.1 discoverability and accessibility are listed as
>>>    the key problems. I think interoperability (between different publications
>>>    of spatial data and between spatial data and other types of data) could be
>>>    listed as a third main problem; many requirements have to do with
>>>    interoperability.
>>>    4. section 1.1: problems that are experienced by different groups
>>>    (commercial operators, geospatial experts, web developers, public sector)
>>>    are described. I get the impression that those problems are the only or
>>>    main problems that are experienced by a certain group, but I don't think
>>>    that is the case. Perhaps the listed problems could be marked as examples?
>>>    Or the list of problems per group could be expanded?
>>>    5. secion 1:1 “we've adopted a Linked Data approach as the
>>>    underlying principle of the best practices ”: Such a statement might drive
>>>    away people that for some reason resist the idea of Linked Data, or in
>>>    general don't like to have to adopt a new unknown paradigm. It also looks
>>>    like the WG was biased in identifying best practices (Linked Data or bust).
>>>    How about stating that upon inspection of requirements and current problems
>>>    and solutions concepts from the Linked Data paradigm transpired to be most
>>>    applicable? Or perhaps Linked Data does not need to be mentioned at all....
>>>    Requirements like linkability, discoverability and interoperability
>>>    automatically lead to recommending using HTTP(S) URIs and common semantics.
>>>    6. I think an explanation of the term 'spatial data' should be
>>>    somewhere very high up in the document (abstract and/or introduction),
>>>    especially that spatial <> geographic (geographical data is a subset of
>>>    spatial data)
>>>    7. Section 2: There seems to be overlap with description of user
>>>    groups in the introduction (1.1). This leads (or could lead) to duplicate
>>>    information. Why not just mention in the introduction that there are
>>>    multiple audiences and that they are described in section 2?
>>>    8. Section 2: I wonder if the three groups that are described cover
>>>    all audience types. Some more I can think of are
>>>    A) People working with spatial data that is not geographical (e.g.
>>>    SVG, CAD, BIM).
>>>    B) People involved in development of standards that have something
>>>    to do with spatial data on the web .
>>>    C) People involved in development of software that can work with
>>>    spatial data.
>>>    9. Section 3: “SDW focuses on exposing the individual; the entities,
>>>    the SpatialThings, within a spatial dataset ”. That seems to exclude
>>>    spatial metadata, which is an important subject in SDW.
>>>    10. “Can be tested by machines and/or data consumers ”: I consider
>>>    data consumers to be humans or machines. In fact, it could be used as a
>>>    useful way of avoiding having to write ''humans or machines' each time.
>>>    Most best practices should benefit both humans and machines. Only in some
>>>    cases the distinction is meaningful.
>>>    11. 6.1: Is the discussion about features, information resources and
>>>    real world things really necessary? I find it slightly confusing and I can
>>>    imagine other will too. Why not just say that if you want spatial data to
>>>    be referenceable on the web you need to use URIs? Just that makes a lot of
>>>    sense and could be less confusing.
>>>    12. Best practice 3: I notice best practices 1 and 2 are phrased as
>>>    solutions or recommendations . I think it is a good idea to try to do that
>>>    for all best practices. So instead of “Working with data that lacks
>>>    globally unique identifiers for entity-level resources” one could write
>>>    “make spatial relationships explicit”
>>>    13. I appreciate seeing references to BP requirements from the UCR
>>>    document. But they are placed in the 'Evidence' section of the BP template
>>>    now. Is it appropriate to count requirements derived from use cases as
>>>    evidence of a best practice? I would expect references to use cases and
>>>    requirements to occur in the 'Why' section of the template. Or in a
>>>    template section that is especially reserved for requirements, e.g
>>>    'Relevant requirements'.
>>>    14. Best practice 8: Is this based on the CRS wiki page
>>>    <https://www.w3.org/2015/spatial/wiki/Coordinate_Reference_Systems>?
>>>    It seems that WGS84 is recommended. But that is debatable and could be
>>>    considered American-centric. European guidelines recommend ETRS89. Also,
>>>    high-precision is not defined. Also, no mention is made of the need to add
>>>    temporal data if a CRS with an increasing error with time (like WGS84) is
>>>    needed. Also no mention is made of how to reconcile local CRSs (as in a
>>>    building plan) with global CRSs. I think CRSs are one of the areas that do
>>>    require some extra standardisation efforts outside of this document, but
>>>    which could be instigated by our working group.
>>>    15. BP 10: I would at least recommend to be aware of significant
>>>    digits.
>>>    16. Appendix C: Why are all UC requirements listed? Why not only the
>>>    BP requirements? That would make a more compact table.
>>>
>>>
>>> Greetings, and keep up the good work!
>>>
>>> Frans
>>>
>>>