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

Re: UCR issue 30: missing requirement

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Wed, 17 Aug 2016 15:00:05 +0200
Message-ID: <CAFVDz43imT_iAFWS+FLtk8AEkRVQ7wUELaBOdQX9nG+nJOEJhw@mail.gmail.com>
To: Jeremy Tandy <jeremy.tandy@gmail.com>, Linda van den Brink <l.vandenbrink@geonovum.nl>, SDW WG Public List <public-sdw-wg@w3.org>, Payam Barnaghi <payam.barnaghi@gmail.com>
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 Wednesday, 17 August 2016 13:00:40 UTC

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