W3C home > Mailing lists > Public > public-egov-ig@w3.org > August 2012

Re: Fw: GeoSpatial vocabularies

From: Paola Di Maio <paola.dimaio@gmail.com>
Date: Wed, 8 Aug 2012 11:23:22 +0100
Message-ID: <CAMXe=SqQ7_G6_mj4+vpp-PKBXqnPA4cV6Z2w7UfMKs-d4-j7Nw@mail.gmail.com>
To: Gannon Dick <gannon_dick@yahoo.com>
Cc: "eGov IG (Public)" <public-egov-ig@w3.org>

Thanks for the detailed post

>From what I understand , you are pointing out some granularity issues
in entity modelling of geospatial data , taking into account some
socio-technical perspective, which we both agree is important.  The
xample of the University vs colleges explains that well i think

But what I do not understand is the relation between the granularity
of the geospatial model, and the fact that all democratic countries
under UN mandate cannot possibly
legally restrict people to share information opinions and knowledge
via public mailing lists (that would be universally illegal, even
though companies and governments may try to muzzle  people who work
for them should not be allowed, as it invalidates their mission

Perhaps you could clarify that?

(Thanks for the Paola's razor attribution, - embarrassed now - but
yes, the line must be drawn at some point.  Glad to see you understand
what I am trying to get to here, altough do not understand the
relation with the geospatial data conversation)

Also not sure what you mean by imaginary participants, which list are
you talking about ?

Thank you


On Tue, Aug 7, 2012 at 8:13 PM, Gannon Dick <gannon_dick@yahoo.com> 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.
> =========
> 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.
> =======
> 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
Received on Wednesday, 8 August 2012 10:23:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:43:23 UTC