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

Re: UCR issue 30: missing requirement

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Fri, 2 Sep 2016 15:27:20 +0200
Message-ID: <CAFVDz40jJ4W001iy__s32CrXmhbHaqAGCWHUSwYP0dqg-uX5PA@mail.gmail.com>
To: Rob Atkinson <rob@metalinkage.com.au>
Cc: Jeremy Tandy <jeremy.tandy@gmail.com>, Payam Barnaghi <payam.barnaghi@gmail.com>, SDW WG Public List <public-sdw-wg@w3.org>, Linda van den Brink <l.vandenbrink@geonovum.nl>
Hello Rob,

It seems to me that since in practice it is difficult to process colloquial
expressions as spatial data this requirement is useful. And, as with other
requirements, I think it is good not to think too much ahead about possible
solutions in the UC&R. Whether or not the requirement can be met by adding
annotation and/or reuse of vocabularies should in principle not influence
the wording of the requirement.

Regards,
Frans

On 1 September 2016 at 14:08, Rob Atkinson <rob@metalinkage.com.au> wrote:

> Its always possible to put text annotation - do we need to say anything
> about this at all?  If on the other hand we have a domain specific
> relationship, this is just a modelling problem that is addressed by the
> reuse of vocabularies BP - your community should publish the terms it cares
> about as a reusable vocabulary, and people should re-use these if suitable,?
>
> Rob
>
> On Thu, 1 Sep 2016 at 20:31 Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
>> I would like to get back to the business of resolving ISSUE-30
>> <https://www.w3.org/2015/spatial/track/issues/30>. Here is a more
>> concrete proposal:
>>
>> Currently the Spatial Vagueness requirement
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialVagueness>
>> reads:
>>
>> *It should be possible to describe locations in a vague, imprecise
>> manner. For instance, to represent spatial descriptions from crowdsourced
>> observations, such as "we saw a wildfire at the bottom of the hillside" or
>> "we felt a light tremor while walking by Los Angeles downtown". Another
>> related use case deals with spatial locations identified in historical
>> texts, e.g. a battle occurred at the south west boundary of the Roman
>> Empire.*
>>
>> We could change it to:
>>
>> *It should be possible for vague or informal expressions of locations or
>> spatial relationships to be useful as spatial data.*
>>
>> *Examples of vague or informal expressions of locations are:*
>>
>>
>>
>>    -
>> *at the bottom of the hillside *
>>    - *downtown Los Angeles*
>>    - *London (has multiple definitions, so just the name is not precise)*
>>
>>
>>    -
>> *the southwest boundary of the Roman Empire *
>>
>> *Examples of vague or informal expressions of **spatial relationships
>> are:*
>>
>>    - *near*
>>    - *across the street from*
>>    - *upstairs*
>>    - *at walking distance from*
>>
>>
>> Are there objections to this change? If so, do you have a alternative?
>> Do we feel that this adequately solves ISSUE-30?
>>
>> Thanks in advance,
>> Frans
>>
>>
>>
>>
>>
>>
>> On 19 August 2016 at 12:22, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>>
>>> On 19 August 2016 at 04:10, Rob Atkinson <rob@metalinkage.com.au> wrote:
>>>
>>>>
>>>> while I'm looking over the requirements document, I notice that there
>>>> are quite a lot of requirements about observations and coverages, such as
>>>>  "5.30 Observed property in coverage"  but no explicit mention of a
>>>> requirement to state the units of measure.  Perhaps simply update 5.30 to
>>>> include this?
>>>>
>>>> Likewise, the only mention of precision is in the cultural heritage use
>>>> case - i would have thought there was a requirement to be able to state the
>>>> spatial and temporal precision of values. In many ways this one of the
>>>> defining requirement for making spatial "special" in terms of a BP ;-)
>>>>
>>>
>>> Hi Rob,
>>>
>>> I think that both requirements are missing because they are not in
>>> scope. If the value of a measurement is published it makes general sense to
>>> indicate the unit of measure. Likewise it is a common requirement to
>>> indicate the uncertainty or precision of a measurement. That goes for all
>>> numerical data, not only spatial or temporal data.
>>>
>>> In fact the requirements are out of scope for data on the web too. If
>>> measurement data are published *anywhere* there should be means of
>>> stating the unit of measurement and the uncertainty. This was rightly
>>> reported to me when I commented on a missing best practise for using
>>> significant digits in the Data on the Web Best Practises document.
>>>
>>> So yes, the coverage specification should allow for indication of units
>>> of measurement and uncertainty, but the way we have been working is that we
>>> understand those requirements to be known general requirements. We have
>>> been trying to scope the explicit requirements to spatiotemporal data
>>> only.
>>>
>>> Regards,
>>> Frans
>>>
>>>
>>>>
>>>> Cheers
>>>> Rob
>>>>
>>>> On Fri, 19 Aug 2016 at 11:58 Rob Atkinson <rob@metalinkage.com.au>
>>>> wrote:
>>>>
>>>>> Mainly it was looking ahead :-)  But IMHO it is important to get the
>>>>> intent, then wording, of such requirements right - is it for there to be
>>>>> guidance for how a community might solve such a problem, or is it for
>>>>> interoperability in the broader ecosystem of tools - i.e. the community is
>>>>> the virtual community of  W3C or OGC standards implementers.
>>>>>
>>>>> GeoSPARQL is the latter case,
>>>>> CRS definitions is the former - but one where the OGC makes
>>>>> recommendations and uses specific CRS definitions as defaults in some
>>>>> specifications.
>>>>>
>>>>> The key thing for this requirement is whether vague descriptions are
>>>>> a) purely textual annotations (in which case we probably dont need to
>>>>> say anything about them at all in the BP)
>>>>> b) qualifications for a geometry property (in which case we probably
>>>>> want to define a vocabulary to identify such properties, and how to bind
>>>>> these to multiple geometries in a single feature - perhaps annotations need
>>>>> to apply to all provided geometries)
>>>>> c) machine-readable constructs (possibly with qualifications) - i.e.
>>>>> the ability to say A isNear B
>>>>>
>>>>> I would suggest its necessary for a BP to handle machine readable
>>>>> location descriptions with human readable annotations, i.e. cases b,c where
>>>>> A relatedTo B  and either A or B is a spatialThing. Note this covers
>>>>> providing a note about geometry per feature.
>>>>>
>>>>> Thus, I'd be tempted to say - in the BP - if the relationship can be
>>>>> expressed using the GeoSPARQL specification, then this should be used,
>>>>> either directly or by specialisation to introduce domain specific semantics
>>>>>  domain-independent spatial operation. Otherwise follow the general BP
>>>>> regarding vocabulary re-use.
>>>>>
>>>>> In, for example hydrology, a description of where a stream gauge is
>>>>> located relative to a stream confluence is actually far more precise than a
>>>>> coordinate somewhere near the confluence - which may be upstream,
>>>>> downstream or at the actual confluence in fact.
>>>>>
>>>>> In the Requirements, therefore, I'd be tempted to rephrase
>>>>> "vague,imprecise"  to "non-coordinate based" - and then identify the above
>>>>> cases and state which is in scope.
>>>>>
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>> On Thu, 18 Aug 2016 at 20:37 Frans Knibbe <frans.knibbe@geodan.nl>
>>>>> wrote:
>>>>>
>>>>>> Hello Rob,
>>>>>>
>>>>>> Was your comment intended as criticism of the proposed rephrasing of
>>>>>> the spatial vagueness requirement? Or is it only looking ahead to
>>>>>> possibilities of meeting such a requirement?
>>>>>>
>>>>>> Although the primary concern of this thread is to formulate the right
>>>>>> requirement(s), I must admit in this particular case it is interesting to
>>>>>> think of possible ways of making it possible.
>>>>>>
>>>>>> Again I think a spatial ontology could be really helpful. Let's take
>>>>>> some examples of text that might be turned into spatial data:
>>>>>>
>>>>>>    1. The Carthaginian army was defeated near the southwest border
>>>>>>    of the Roman empire.
>>>>>>    2. The suspect moved from the entrance of the bank to a red car
>>>>>>    that was parked near the post box.
>>>>>>
>>>>>> The first example might come from a historical source and the second
>>>>>> could be an example of crowd sourced data, two use cases in which vague
>>>>>> spatial data are typically encountered.
>>>>>>
>>>>>> A hypothetical spatial ontology will have definitions of the concepts
>>>>>> of 'spatial thing' and 'spatial relationship'. So at least we could flag
>>>>>> the locations and the spatial relationships in these statements as such.
>>>>>> That could already be helpful.
>>>>>>
>>>>>> Now in the first example it is imaginable that a resource exists that
>>>>>> defines the terms used in a domain context. Historians studying the Roman
>>>>>> empire could make a vocabulary in which the general classes for
>>>>>> location and spatial relationships are specialised. It could have a
>>>>>> collection of linestrings marking the borders of the empire through
>>>>>> time, and it could have a definition of the spatial relationship 'near',
>>>>>> which in historical Roman texts could always mean 'a distance of at most
>>>>>> one day's marching'. Furthermore, the spot where the battle took
>>>>>> place could be represented as a 2D point geometry with unknown coordinates
>>>>>> (by the way, a possible example of why the coordinates should not be a
>>>>>> mandatory part of a geometry).
>>>>>>
>>>>>> For crowd sourced information, definitions of vague terms that are
>>>>>> used will probably be more difficult to outsource to domain vocabularies.
>>>>>> Definitions of terms can be as diverse as the crowds using the terms. But
>>>>>> at least flagging the locations and spatial relationships using the general
>>>>>> spatial ontology could be useful.
>>>>>>
>>>>>> Regards,
>>>>>> Frans
>>>>>>
>>>>>> On 18 August 2016 at 01:10, Rob Atkinson <rob@metalinkage.com.au>
>>>>>> wrote:
>>>>>>
>>>>>>> IMHO this is covered by the general vocabulary re-use clause - such
>>>>>>> vague terms are domain specific semantics - therefore in general you should
>>>>>>> look to re-use a set of relationship properties, as defined in an ontology,
>>>>>>> published by the community of practice you intend your data to be
>>>>>>> understood by/interoperable with.
>>>>>>>
>>>>>>> In general, one should look first  to the OGC for spatial concerns,
>>>>>>> to see if such a community has either published what you need, or has a
>>>>>>> governance structure in place (a Domain Working Group) where such a
>>>>>>> vocabulary can be shared. (note that OGC will reference relevant
>>>>>>> vocabularies published by other SDOs.... so its a sensible starting point
>>>>>>> IMHO)
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>> On Wed, 17 Aug 2016 at 23:10 Joshua Lieberman <
>>>>>>> jlieberman@tumblingwalls.com> wrote:
>>>>>>>
>>>>>>>> Can we distinguish between qualitative relationships such "bottom
>>>>>>>> of the hillside” which are as precise as the features being referenced,
>>>>>>>>  and fuzzy ones such as “near the hillside” that explicitly use imprecise
>>>>>>>> relationships?
>>>>>>>>
>>>>>>>> Josh
>>>>>>>>
>>>>>>>> On Aug 17, 2016, at 9:00 AM, Frans Knibbe <frans.knibbe@geodan.nl>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Dear group members, especially the BP editors,
>>>>>>>>
>>>>>>>> It would be great if we can resolve this sleeping issue
>>>>>>>> <https://www.w3.org/2015/spatial/track/issues/30> before the next
>>>>>>>> PWD of the UC&R document. To summarise the issue, it seems clear
>>>>>>>> what the requirement is: there is a need to be able to use
>>>>>>>> vague/informal/colloquial expressions to refer to either spatial things or
>>>>>>>> spatial relationships.
>>>>>>>>
>>>>>>>> I still think the easiest solution is to change the existing Spatial
>>>>>>>> vagueness
>>>>>>>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialVagueness>
>>>>>>>> requirement a bit. The core requirement would then be something like "It
>>>>>>>> should be possible to use vague or informal expressions to indicate
>>>>>>>> locations or spatial relationships". That requirement could be followed by
>>>>>>>> some examples:
>>>>>>>>
>>>>>>>> for locations:
>>>>>>>>
>>>>>>>>    - at the bottom of the hillside
>>>>>>>>    - downtown Los Angeles
>>>>>>>>    - London (has multiple definitions, so just the name is not
>>>>>>>>    precise)
>>>>>>>>    - the south west boundary of the Roman Empire
>>>>>>>>
>>>>>>>> for spatial relationships:
>>>>>>>>
>>>>>>>>    - near
>>>>>>>>    - across the street from
>>>>>>>>    - upstairs
>>>>>>>>    - at walking distance from
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Frans
>>>>>>>>
>>>>>>>> On 20 October 2015 at 14:04, Frans Knibbe <frans.knibbe@geodan.nl>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-10-16 11:15 GMT+02:00 Jeremy Tandy <jeremy.tandy@gmail.com>:
>>>>>>>>>
>>>>>>>>>> Hi Frans-
>>>>>>>>>>
>>>>>>>>>> I'm not sure that your option (1) covers the terms used for
>>>>>>>>>> 'vague' (or, more accurately, _relative_) spatial relationships. I think
>>>>>>>>>> that we might want to refer to the location of a post box unambiguously,
>>>>>>>>>> based on it's position within a topological (road) network; e.g. 150 from
>>>>>>>>>> the junction of roads A and B in the direction of [etc.] ... the junction
>>>>>>>>>> (a node in the network) might have a geometric position (e.g. collected by
>>>>>>>>>> a surveyor with GPS), but the position of street furniture may be recorded
>>>>>>>>>> using relative positions.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We already have a requirement for being able to use spatial
>>>>>>>>> relationships, see the Spatial relationships requirement
>>>>>>>>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialRelationships>.
>>>>>>>>> If that requirement is met, it should be possible to express the location
>>>>>>>>> of a post box relative to some topographic or topological point, wouldn't
>>>>>>>>> you say?
>>>>>>>>>
>>>>>>>>> However, the ability to be vague about relative positioning does
>>>>>>>>> not seem to have been addressed yet. One might want to say that a post box
>>>>>>>>> is close to the butcher shop, or over the road from the bakery.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Frans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Does that help?
>>>>>>>>>>
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On Wed, 14 Oct 2015 at 13:17 Frans Knibbe <frans.knibbe@geodan.nl>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Rachel and Jeremy, thank you for helping us solve this case.
>>>>>>>>>>>
>>>>>>>>>>> So this is about being able to use colloquial terms for both
>>>>>>>>>>> location and spatial relationships. It seems to me that the first
>>>>>>>>>>> part, colloquial terms for location is basically covered by the Spatial
>>>>>>>>>>> vagueness requirement
>>>>>>>>>>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialVagueness>.
>>>>>>>>>>> Interestingly enough, this requirement has not been related to the Best
>>>>>>>>>>> Practices requirement.
>>>>>>>>>>>
>>>>>>>>>>> What we could do is:
>>>>>>>>>>>
>>>>>>>>>>>    1. Rephrase the spatial vagueness requirement a bit to make
>>>>>>>>>>>    it clearly cover examples like “the midlands”, “town centre”, how different
>>>>>>>>>>>    people define “London”.
>>>>>>>>>>>    2. Relate the spatial vagueness requirement to the Locating
>>>>>>>>>>>    a Thing use case
>>>>>>>>>>>    <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#LocatingAThing>
>>>>>>>>>>>    and the Best Practices deliverable
>>>>>>>>>>>
>>>>>>>>>>> For the requirement to be able to use colloquial terms for
>>>>>>>>>>> spatial relationships we could either expand the definition of
>>>>>>>>>>> the Spatial vagueness requirement, or add a new requirement, so that we end
>>>>>>>>>>> up with separate requirements for spatial vagueness for locations and
>>>>>>>>>>> spatial vagueness for relationships. I would favour the first option, to
>>>>>>>>>>> keep things simple, and because there is of plenty of overlap between the
>>>>>>>>>>> requirements.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Frans
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2015-10-13 18:03 GMT+02:00 Jeremy Tandy <jeremy.tandy@gmail.com>
>>>>>>>>>>> :
>>>>>>>>>>>
>>>>>>>>>>>> Hi-
>>>>>>>>>>>>
>>>>>>>>>>>> Rachel is correct; 'Locating a thing' [1] (provided by
>>>>>>>>>>>> @eparsons) is the source of this requirement. The description provided in
>>>>>>>>>>>> her message is accurate. Ed also uses phrases like "upstairs", "where I
>>>>>>>>>>>> left it" etc.
>>>>>>>>>>>>
>>>>>>>>>>>> It's not about geocoding; it's about relating position in human
>>>>>>>>>>>> terms ... all about context.
>>>>>>>>>>>>
>>>>>>>>>>>> FWIW, there are already some reasonable models from OGC about
>>>>>>>>>>>> describing relative positioning - usually related to position within a
>>>>>>>>>>>> topological network offset from a node in that network (e.g. position of
>>>>>>>>>>>> signage on a railway, position of a lamp post on a street etc.)
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>
>>>>>>>>>>>> [1]: http://w3c.github.io/sdw/UseCases/
>>>>>>>>>>>> SDWUseCasesAndRequirements.html#LocatingAThing
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, 9 Oct 2015 at 17:37 Heaven, Rachel E. <reh@bgs.ac.uk>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Frans
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looks like this is from the “Locating a thing” use case,
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.w3.org/2015/spatial/wiki/Working_Use_
>>>>>>>>>>>>> Cases#Locating_a_thing...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It’s about vernacular geography :  human terms for relative
>>>>>>>>>>>>> spatial positioning (“upstairs”, “over the road from”) and human concepts
>>>>>>>>>>>>> of places (“the midlands”, “town centre”, how different people define
>>>>>>>>>>>>> “London”). These extents are usually vague and do not match official
>>>>>>>>>>>>> authoritative boundaries, so you can’t geocode them accurately, if at all.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It will also be very relevant to harvesting crowd sourced data
>>>>>>>>>>>>> https://www.w3.org/2015/spatial/wiki/Working_Use_
>>>>>>>>>>>>> Cases#Crowd_sourced_earthquake_observation_
>>>>>>>>>>>>> information_.28Best_Practice.2CSSN.29
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Rachel
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl]
>>>>>>>>>>>>> *Sent:* 09 October 2015 14:11
>>>>>>>>>>>>> *To:* SDW WG Public List; Kerry Taylor; Jeremy Tandy
>>>>>>>>>>>>> *Subject:* UCR issue 30: missing requirement
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is the thread for discussion of UCR issue 30
>>>>>>>>>>>>> <http://www.w3.org/2015/spatial/track/issues/30>, the Case of
>>>>>>>>>>>>> the Mysterious Missing Requirement.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The current description reads: '*see " relative (spatial)
>>>>>>>>>>>>> relationships based on context e.g. my location [expressing location and
>>>>>>>>>>>>> places in human terms] " from *
>>>>>>>>>>>>>
>>>>>>>>>>>>> *https://www.w3.org/2015/spatial/wiki/BP_Consolidated_Narratives#linking_data
>>>>>>>>>>>>> <https://www.w3.org/2015/spatial/wiki/BP_Consolidated_Narratives#linking_data>'. Jeremy
>>>>>>>>>>>>> might know what use case it came from.'*
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> To me is not exactly clear yet what the requirement could be.
>>>>>>>>>>>>> Resolving location names in human terms to geometry is called geocoding and
>>>>>>>>>>>>> is a well established practice. Could this be about the need for having
>>>>>>>>>>>>> human language equivalents for spatial relations? I can see that would be a
>>>>>>>>>>>>> benefit for finding spatial data using a search engine.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we find the related use case(s) we will probably get a
>>>>>>>>>>>>> better idea of what the missing requirement could look like,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Frans
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>> This message (and any attachments) is for the recipient only.
>>>>>>>>>>>>> NERC is subject to the Freedom of Information Act 2000 and the contents of
>>>>>>>>>>>>> this email and any reply you make may be disclosed by NERC unless it is
>>>>>>>>>>>>> exempt from release under the Act. Any material supplied to NERC may be
>>>>>>>>>>>>> stored in an electronic records management system.
>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>
Received on Friday, 2 September 2016 13:27:51 UTC

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