Re: UCR issue 30: missing requirement

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