Re: UCR issue 30: missing requirement

Hello all,

I have just made the proposed change to the document (here
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialVagueness>)
and I have closed issue-30.

Regards,
Frans

On 2 September 2016 at 15:27, Frans Knibbe <frans.knibbe@geodan.nl> wrote:

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