Re: My BP comments

Hi Frans- I've added ISSUE 213 <https://github.com/w3c/sdw/issues/213> into
the BP doc (Appendix C) to remind us to do the work you suggest.

Jeremy

On Wed, 13 Jan 2016 at 17:29 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:

> > 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
>>>>
>>>>