Re: UCR issue 30: missing requirement

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/SDWUseCasesAndRequire
>>>>>>>>>> ments.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.
>>>>>>>>>>> ------------------------------
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>