Re: GeoSpatial vocabularies

My point was if there is a (slight) disagreement between experts, it should be this:
1. The metadata of a Point of Interest is only viewable right straight down the Normal because it is a spectral image.  The elliptical region around the Point of interest must at some point degenerate to a circle, computable with some error, by Classical Newtonian Mechanics and plane geometry (and RDF List Classes).
2. Make the elliptical view port smaller by drawing a smaller ellipse around an Address.

Approach #2 leads to much more complex spectra, which, IMHO, only satisfy a desire for continued complexity. Its roots are in Resonance Imaging, and the results are the replacement of a remote head count by a remote hair count.  A useful result would be a hair color distribution.  This approach is effectively a view in the side window of a silo from near ground level.   At that point, you are viewing combitorial artifacts having dismembered the Members of the Community rdf:List.  In simpler terms: it is not necessary to plot a Great Circle route to the Kitchen and Coffee Maker in the morning, even though in theory, you can.

This mashup of the University of Oxford is not hugely enlightening because it measures the "Eastiness" and "Northiness" of (the center of mass of) Oxford through the years - the Concepts may not be useful, but the data view is accurate.  http://www.rustprivacy.org/2012/roadmap/oxford-university-area-map.pdf

--Gannon






________________________________
 From: Phil Archer <phila@w3.org>
To: Gannon Dick <gannon_dick@yahoo.com> 
Cc: Public LOCADD list <public-locadd@w3.org> 
Sent: Friday, August 24, 2012 5:49 AM
Subject: Re: GeoSpatial vocabularies
 
Protocol: I hate to cross-post so I'll post this just to LOCADD CG's own 
list. Original was to both GLD and LOD lists - I'll point to this reply 
from there.

Apology: for my slow response, I've been on holiday.

Substance: The points you raise are all entirely valid and, as ever with 
your contributions, a tad mind-bending. However... I fear I may have 
mislead you. The LOCADD Community Group is not going to try and create a 
new way of representing geometries (points, lines and polygons) and 
things like A is within B and borders C - that's all been done (GML, WKT 
etc.) what we're looking at is how to marry that geospatial data with 
linked data in a way that makes sense to experts in both of those 
fields. It is the (slight) disagreement on the best way to proceed that 
is at the heart of this.

Actually, your example of the the University of Oxford would, I think, 
be a Point Of Interest. Such things can have one location, or multiple 
locations and some of those may be moving. For example, the point of 
interest might be the car in front that's travelling at the same speed 
as you.

As for participants, we're currently at 21 including a number of noted 
geospatial folk [1]. It's getting more support than I dared hope for 
although I still have some individuals I need to tap on the shoulder and 
encourage to join.

HTH

Phil.

[1] http://www.w3.org/community/locadd/participants

On 07/08/2012 20:08, Gannon Dick wrote:
> 1. Couldn't find the proposal for this Group.  How many imaginary participants have signed up ?
>
> 2. "Paola's Razor" - with apologies to William of Occam/Law of Parsimony - Paola Di Maio said: "... but as far as I know the democratic world mandates
> and promotes free speech in all its forms :-)".  This is an important entailment for geolocation systems.  The (Statistical/RDF) Properties (scalars) of a particular region must be integrated and non-discriminatory.  For example, the systemic location of the University of Oxford cannot be broken down to the locations of the 38 Colleges and 6 PPH's.  This is important because Mobile Devices are points not regions.  Forty-four Oxford University cell phones should return the same location - an abstract rooftop called "Oxford University" in something called Oxfordshire.  This is real space, not hyperspace.
>
> 3. The tiny little location range (ca. 4 inches for a satellite photograph ) of Mobile Devices has be balanced with the radial metrics of socio-political entities, otherwise the over magnification problem leads to false conclusions.  In any given region, (Population > Mobile Devices)  AND (Population > Households).  The quantitative relation of Mobile Devices and Households is unknowable.  For personal privacy, back up just a minute ... who told MS (Bing) and Google Earth they could map my roof in 4" squares ?
>
> 4. The "picture" of locations as crystalline locations (close packing of spheres) is also wrong, since there is a hyperspace distance between the centers.  As above, with two regions (Population[1] > Population[2]) OR (Population[1] <= Population[2]).
> 5.  The difficulty with writing RDF for locations is that the Classes must all be scalars with units in a system (RDF) without scale. Regional metrics cannot be fungible (like currency) because that type has variable frequency.  For example, suppose you knew the ratio of Population to Housing Units for Oxfordshire and wanted to make a guess at the food bill for an average household.  So you tally the Meals Eaten per Week (as a Household) ... you get a number of frequency spectra depending on various "business" cases but vary the cost of food and you get stock ticker looking noise.  This uncertainty is the model's fault, not the measurer's fault.
>
>
> Is there a simpler way ?  Yes, avoid the XKCD Trap by being only as complex as you need to be and ("Paola's Razor", FEAR IT!) being considerate of people not like you.
>
>
> Have a look at this picture: http://www.rustprivacy.org/2012/roadmap/gs-cell.png
>
> The center of your Community [box] is the star in the middle.  The distance from the star to the box perimeter is how long it takes people in your Community to get to work (point w).  Other tasks (point t), besides work (getting a haircut, shopping for groceries, etc.) are all on the Society [circle].  Hyperspace permeates all - the outside box being the boundary - or you can say Community is fixed in Society which is floating around in Cyberspace.  That's it.  Now to put numbers on ...
>
> FIPS (Federal Information Processing Standards) can be reduced to a Web Domain Identifier.
>
> For each County and County Subdivision, Population, Housing Units (Occupied), Land Area, Water Area, Latitude, Longitude and Time Zone (Some Counties are split - this is the Oxford University problem above).  The Census also provides an average commute to work, by County.  The uses for this take a little explanation ... In classical Physics, Power = Work/Time and Speed = Distance/Time.  In the real world, The time required to get to the task "work" places an upper limit on the power required to accomplish other tasks.  This is a little hard to wrap your head around, but remember you are talking about "local" averages and indeed this "law" is locally true*.  For every you with a grocery store next door, there is someone else with the grocery store 10 feet past the office.  The Census Bureau publishes the average commute to work by County.  As a practical matter multiply MTT by a speed 160 km/hr, 2 mph on foot, etc, and you get a relative estimate
>   of the power consumed which will not veer off into impossible to conceptualize complex arithmetic.
>
> An example "profile" for Rhode Island is here: http://www.rustprivacy.org/2012/roadmap/profile-RI.txt
>
> The "almost done" National Profile has almost 40,000 identifiers.
>
> --Gannon
>
>
> [*]  This is how Lord Kelvin messed up the Age of the Earth.  Hopefully the University of Southampton has better engineers than the University of Glasgow. Phil ?  Any career ending thoughts for us ? :-)
>
>
> ----- Original Message -----
> From: Phil Archer <phila@w3.org>
> To: Public GLD WG <public-gld-wg@w3.org>; "public-lod@w3.org" <public-lod@w3.org>
> Cc:
> Sent: Monday, August 6, 2012 7:46 AM
> Subject: GeoSpatial vocabularies
>
> Having been involved with a number of conversations recently, and being aware of many more, I am proposing a new Community Group around vocabularies for describing locations.
>
> See http://www.w3.org/community/groups/proposed/#locadd
>
> Background
> ==========
> This is hardly a new idea and the last thing I want to do is to fall into the XKCD trap [1]. Nevertheless, we have different organisations having similar but separate conversations at the moment, mostly born of different use cases and perspectives. This is normal but I think some sort of coordination could be beneficial.
>
> GeoSPARQL
> =========
> The OGC has completed work on GeoSPARQL [2]. This is favoured by the likes of (UK mapping agency) Ordnance Survey and has been produced primarily by geospatial experts with an interest in linked data.
>
> NeoGeo
> ======
> A community effort has produced NeoGeo [3]. This is favoured by the likes of (French mapping agency) IGN and has been produced primarily by linked data experts with an interest in geospatial data.
>
> The primary difference between GeoSPARQL and NeoGeo is in the way they handle point, line and polygon literals. Both enjoy significant support and implementation experience.
>
>
> INSPIRE
> =======
> Is a European Commission Directive that legally obliges the Member States of the European Union to publish environmental and geospatial data using a common set of standards which are under various stages of development [4].
>
>
> ISA Programme Location Core Vocabulary
> ======================================
> Produced by a working group chaired by the team responsible for the development of INSPIRE under the auspices of a different part of the European Commission, this very lightweight vocabulary includes properties and classes for describing locations and for recording addresses in a manner conformant with INSPIRE - a feature not shared by vCARD for example. Now a work item of the W3C Government Linked Data WG [5], the vocabulary needs further community review and refinement [6].
>
>
> schema.org
> ==========
> Includes basic classes and properties for locations including:
> - addresses (a clone of vCard) http://schema.org/PostalAddress
> - lat/long (a clone of WGS84) http://schema.org/GeoCoordinates
> - geoShape (including boc, circle, line & polygon) http://schema.org/GeoShape
>
> It inherits things like name, URL and description from schema.org/Thing which are at least analogous to things like Geographic Names and Geographic Identifiers.
>
> schema.org includes containedIn but not, AFAICT, borders etc. The schema.org location properties seem closely linked with event vocabulary. Classes include Mountain, Body of Water, Continent etc.
>
> The current list of proposed extensions to schema.org [7] does not include anything in this space and there is no (visibly active) discussion associated with schema.org and location.
>
>
> W3C Point of Interest
> =====================
> I'm sorry to say that the Points of Interest WG [8] seems to have hit the buffers so that the March 2012 draft [9] looks like being as far as it gets. This just at a time when more and more data is being published, a lot of it related to locations and, well, points of interest. The ideas behind the POI WG remain as important as ever but it seems that a new focus is necessary if that work is to be leveraged effectively.
>
>
> Standards bodies
> ================
> OGC and W3C are both willing to help if required but what actually *is* required? That's what the proposed community group is to find out. When we know that, we can look at where any work should be done. Like any membership organisation, both W3C and OGC put the wishes of their members first. Both bodies are very willing to work together.
>
>
> Possible outcomes
> =================
> One possible outcome is a standard that is backwards compatible with GeoSPARQL and NeoGeo and that combines aspects of both. The danger there is that this would lead to an over-complex standard that could never be fully implemented - which is about as big a pointless waste of time as can be imagined. However, the two are close and common ground shouldn't be hard to find.
>
> At the other extreme is that everyone carries on in in their own way and, well, people can pick and choose. This seems less than ideal to me. If interoperability between data sets is important then we need to make some effort to coordinate.
>
> The gaps seem to be around linked-data friendly INSPIRE standards, particularly wrt addresses, and in handling geometry literals that can be huge (no one is talking about yet another way to define points lines and polygons btw!).
>
> What I hope the proposed group could achieve is:
>
> - consensus on the use cases/gaps that need be filled;
> - at least a rough solution that takes full account of the existing work highlighted here.
>
> If that can be done, the GLD WG's charter would allow it to take this through the W3C Recommendations Track, assuming the continued support and interest of the community. The WG itself does not have the resources and geospatial expertise to see this through on its own.
>
> If this interests you, do please join the Community Group at http://www.w3.org/community/groups/proposed/#locadd and post your ideas.
>
> Thank you
>
> Phil.
>
>
>
> [1] http://xkcd.com/927/
> [2] http://www.opengeospatial.org/standards/geosparql
> [3] http://geovocab.org/doc/neogeo/
> [4] http://inspire.ec.europa.eu/index.cfm/pageid/2
> [5] http://www.w3.org/2011/gld/
> [6] http://philarcher.org/isa/locn-v1.00.html although officially I should point you to http://joinup.ec.europa.eu/asset/core_location/home
> [7] http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals
> [8] http://www.w3.org/2010/POI/
> [9] http://www.w3.org/2010/POI/documents/Core/core-20111216.html
>
>

-- 


Phil Archer
W3C eGovernment
http://www.w3.org/egov/

http://philarcher.org
+44 (0)7887 767755
@philarcher1