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

Re: Mashups with Socio-Technical Systems

From: Gannon Dick <gannon_dick@yahoo.com>
Date: Thu, 26 Jul 2012 15:32:17 -0700 (PDT)
Message-ID: <1343341937.84790.YahooMailNeo@web112620.mail.gq1.yahoo.com>
To: "eGov IG \(Public\)" <public-egov-ig@w3.org>
I won't be able to make the call tomorrow, but with reference to the Linked Data Best Practices ...

I obtained [1,2,3] and loaded them up to a data base to get counts by US State of the number of identifiers (Linked Data URI's) one would need to cover the US with abstract "Cell Towers"  (a point and a radius is all you need to "map" this on Earth Explorer, see below), but then you have access to considerable data (Science, Weather, etc.) and you also have a tool to plan new data collection efforts.

From the lists[4], it's clear that if Federal,State,County and Municipal Governments are going to be delivering data over a Mobile Device, that a pick list with 30,000+ choices is out of the question.  The D2R Server has a "suggested" limit of 50 at a time.

There is a better way to specify an identifier ... XML can be set up in nested Russian Doll fashion, that is recursively.  This is not possible with HTML.  Two examples are included (Tarrant Co. Texas and Santa Clara California).  They validate against a DTD, and I wrote one of these recursive XSD's several years ago.  I know they work :-)

[1] Counties http://www.census.gov/geo/www/gazetteer/gazetteer2010.html

[2] County Subdivisions http://www.census.gov/geo/www/gazetteer/gazetteer2010.html

[3] AWIPS http://www.nws.noaa.gov/geodata/catalog/wsom/html/cntyzone.htm (includes Time Zones, etc.)

[4] http://www.rustprivacy.org/2012/roadmap/county-counts.zip

 From: Gannon Dick <gannon_dick@yahoo.com>
To: eGov IG (Public) <public-egov-ig@w3.org> 
Sent: Sunday, July 22, 2012 2:05 PM
Subject: Mashups with Socio-Technical Systems

The current lawsuits over voter ID[1] in the US and the structure of the Mobile Web represent two opposing facets of eGovernment technology.  To "comment" on Government Policy, society holds elections.  Governments are to deliver services to communities via the Mobile Devices.  That is the plan, but not such a good plan if it entails modification of society and community to suit the (somewhat fluid) needs of the web.

Federal, State, County and Municipal Governments use the same delivery channel.  Do they share it
 nicely ?  Well, that is the problem.  Two voters have a linked data relation via society at large, two trees in a forest, so to speak.  However,  two Mobile Devices do not make a household.  A comparable linked data relation via community does not exist. The competition for the delivery channel leads to walled gardens, data silos and, for a time,  multiple winners.  Governments are a balance of Society and Community interests and cannot support winners and losers over any substantial length of time.  Hence the term Socio-Technical Systems to denote trivial marshaling issues where the needs of society must come before those of community in time.  First you build linked data, then if necessary, make repairs to hyperlinks, so it is with any road, river bridge or infrastructure project.

eGovernment Apps with regional and local coverage have the basic framework for interoperability with both society and
 community as defined above[2].  The data need only be put into convenient form[3] for use in MashUps of socio-economic data.  This is in the eGov Roadmap.  

For the EU to avoid a "War Between the States" as the US Civil War is called, then both the US States and the EU Member States and must avoid a power struggle for the citizens' attention.
If Federal, State, County or Municipalities are defined as a group of Mobile Device identifiers, linked data may fail since delivery channel conflicts remain.


[1] http://www.brennancenter.org/content/resource/the_challenge_of_obtaining_voter_identification
[2] http://earthexplorer.usgs.gov/
[3] (Handy stuff, datasets zip file) http://www.rustprivacy.org/2012/roadmap/socio-technical-sys.zip
Received on Thursday, 26 July 2012 22:32:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:47 UTC