[OSGeo-Standards] [REST.SC] Was: "file" formats. Is: GeoWeb
creed at opengeospatial.org
Tue Jul 16 16:02:16 PDT 2013
Well, Sahana uses a number of catalogs and registries:
http://sahana.davisnz.org/www/index.php?mod=cs&act=default (aid catalog)
http://sahana.davisnz.org/www/index.php?mod=mpr&act=default (missing person
And Ushahidi references Google Maps API which in terms references an imagery
I do not think the argument is about the value of social networks. The OGC
community is involved in numerous projects and applications that are dealing
with citizen scientists, crowd-sourced geo-content and so forth. One example
However, this does not minimize the need for some type of registry/catalog
technology and the interfaces that support CRUD activities to those
resources. Sure, traditional catalog interfaces have often been difficult
and time consuming to use, although automated metadata and CSW apps have
made this process much easier. I think we need to perhaps separate the
discovery of something I tweet versus discovery of a massive imagery archive
with substantial associated metadata - such as provided by DigitalGlobe,
ESA, NASA, NGA, and so forth. In these large systems, cataloguing is often
an automated part of the process. If "enabled" by some consistent API or
interface (RESTful, CSW or whatever), then data discovery is facilitated.
Further, there is the quality and other metadata associated with the imagery
that can be used to determine fit for purpose.
One of the big study areas in COBWEB is determining analytical techniques
for determining the quality of and the consistency of collection of crowd
sourced geo content.
As to FaceBook, Twitter, Google etc I believe that they all use Hadoop and
MapReduce. There are numerous activities to spatially enable Hadoop. An
interesting presentation here:
. Many of the primary data sources are the US Government - USDA, USGS, etc.
Guess what: they are have extensive catalogues. EBay has an extensive
catalog API. Many other technology platforms suggest they do not have
catalogs but if one digs more deeply, one finds catalogues disguised as
Anyway, I think that both approaches have high value and the OGC as a
community should think about harmonious utilization of a range of solutions
to solve our data sharing and processing issues - and avoid some of the
either or discussions that we seem to get dragged into on an increasing
My late afternoon missive . . . Hopefully this email does not start another
rat-hole (IETF term) discussion!
From: Pat Cappelaere
Sent: Tuesday, July 16, 2013 2:06 PM
To: Jeff de La Beaujardiere
Cc: Frye Stuart ; standards at lists.osgeo.org (OSGeo) ; Mandl Dan ; Karen Moe
(GSFC-4070) ; REST SC
Subject: Re: [REST.SC] [OSGeo-Standards] Was: "file" formats. Is: GeoWeb
On Jul 16, 2013, at 2:46 PM, Jeff de La Beaujardiere
<jeff.delabeaujardiere at noaa.gov> wrote:
> Sorry, but I must disagree strenuously with this statement:
> On 2013-07-16 12:42, Pat Cappelaere wrote:
>> Information gets disseminated quicker via social networks and story
>> telling. Think Facebook / Twitter.
>> Users mimick what their friends tend to do.
>> They click on links and eventually get access to similar products for
>> their own area. No coding involved.
> The *essential goal* of establishing catalogs and harmonizing services and
> formats is so that you no longer need to know someone who knows someone
> who has used those data before and knows where to find them and how to
> decode them!
I am all for harmonizing services. This is what the Open GeoSocial API is
about so users can deal with disparate service types and bindings.
I hear what you are saying about the goal of catalogs.
I am responding to Carl's request for a pragmatic REST interface.
I responded based on the work we are doing with non sophisticated GEOSS end
users. Catalogs are too hard to use for us, developers and users. They do
not evolve as the rest of the system does and become obsolete quickly. This
is not a sweeping statement but limited to our current experience. I can
provide examples, if necessary, of dead links…
> In my opinion this proposition of finding data through social networks is
> a huge step backward. It is inefficient and does not scale.
I am not sure I agree with that statement. Can you elaborate? AFAIK,
Facebook, Twitter and Google have proven the opposite.
It is a fact that this is how most people get their information from these
days (may be not us, that's a fact)
> People who need to do real work do not mimic what their friends do--they
> repeat what they have done before and what they know how to do well. If
> they are smart people or have good tools they will try something new. If
> they only have a browser they go to a search engine. However, they do not
> see whether their friend also happens to be working on the same thing
> unless they are already collaborators, in which case setting up some sort
> of social infrastructure to allow them to communicate is largely
> redundant. Social networks are great for learning that a disaster is
> occurring and getting human-interest stories, or for learning about a new
> result in science, but they are not great for actually obtaining and
> analyzing digital data for emergency response, or for doing the original
> thinking and research that leads to the new science results.
Social networks have been actually extremely effective during every recent
disaster. And they will get more and more effective. So I am baffled by
Citizen science is now enabled with that technology. We are only seeing the
tip of the iceberg.
We are not talking about data analysis but data/product discovery. As soon
as those products are available on Facebook or via twitter, they go
immediately viral. So I am really puzzled. Look at USHAHIDI for example.
Scientists will still do what they do… but more and more they will
participate with a larger open community (think OpenStreetMap) using
different means aka social networks.
I think that it is a good thing to open up to a larger user community and
try to make it easier for them to discover, access and share information.
It does rely on lower level interfaces that have been designed over the
years (it is not a replacement by any mean)
REST.SC mailing list
REST.SC at lists.opengeospatial.org
More information about the Standards