[georss] [Mass-Market-GEO] OpenSearch Geo - Feedback

Wed Oct 24 00:44:08 EDT 2007

Jason -

The OGC has coordinated a number of teleconferences and email discussions
on providing governance, a "resolver", and a registry for use with OGC
urn's. This is all required as part of our obtaining an official OGC NID.
The OGC NID proposal is working its way through the final steps in the
IESG/IANA approval process.

AS I am out of the country, I do not have all of the URLs at my
fingertips. Check with Greg Buehler. He can provide the URLs to the OGC
NIS information page and the beta "resolver".

Just thought that this might be of interest. All is public (or will be
once we get the kinks out).

Regards

Carl

> GML has a lot of the ingredients to make it successful in the REST
> space: the use of URIs as identifiers for features and feature types.
> Only secondarily would be the use of XML (not necessary, but a solid
> representation). And, if you're going have linking, then xlink is the
> way to do it if using XML and URIs.
>
> I see more systems using UUIDs in the database, which may seem more
> compatible with the URN notation (urn:uuid:xxx...), but without a method
> of resolving those URNs, you're still against a wall wrt the web.
>
> This is assuming that people/organizations will want to use DNS to
> identify their data and only secondarily the bare UUIDs, e.g.
> http://cooldata.corp/transportation/foo/bar/123... instead of
> urn:uuid:r.a.n.d.o.m.d.i.g.i.t.s (what these URNs gain in precision and
> uniqueness, they lack in marketing/aesthetic attractiveness which
> shouldn't be discounted in the mass-market)
>
> I think some of these naming/identification problems might me mitigated
> by using other REST concepts: representations and linking. An example of
> this is using WFS (typically accessed by DNS) to get feature IDs, which
> could be in the urn:uuid:xxx form. WFS, however, doesn't quite work the
> way HTTP is suppose to though...
>
> - Jason
>
>
>
> -----Original Message-----
> From: Ron Lake [mailto:rlake at galdosinc.com]
> Sent: Wednesday, October 17, 2007 11:47 AM
> To: Jason Cupp; georss at lists.eogeo.org
> Subject: RE: [georss] [Mass-Market-GEO] OpenSearch Geo - Feedback
>
> Hi Jason:
>
> How do you see this in terms of the role of databases.  At the origin of
> GML, we considered the idea that most geographic data might in the
> future NOT reside in databases, but simply exist as files (documents) on
> the web.  It was for this reason that GML objects have gml:ID (of type
> XML ID) so that global references could be constructed as URL's to any
> GML object.  We then saw such resources as being linked to one another
> and hence the origin of the use of xlink:href on GML properties, the
> value of the property being obtained by traversing the link.  These
> concepts do fit the web, but seem to have more problems in fitting into
> database management systems.  Do you see it this way or do you think
> that database management systems do not raise any special issues?
>
> Sincerely,
>
> Ron
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Jason Cupp
> Sent: October 17, 2007 11:23 AM
> To: georss at lists.eogeo.org
> Subject: Re: [georss] [Mass-Market-GEO] OpenSearch Geo - Feedback
>
>> You say that in the web " hypertext as the engine of application
> state"
> - what do you mean by that?
>
> I think this is the most novel and exciting thing that is happening as
> Web services become more RESTful.
>
> A lot of it has to do with URL construction. When humans browse the web,
> we follow links, but this isn't typically how web services work. You can
> see a little of this in the OGC capabilities documents. Those documents
> contain hyperlinks to URLs that are 'home' to specific operations -- but
> that's about it, the rest is left to the URL construction (KVP) and POST
> XML rules.
>
> Other things that would make (OGC) services more RESTful (for catalog
> search at least):
>
> * the result set representations contain links for [previous] and [next]
> result set. No need to perform URL construction, the link is provided.
> * the result set contains links for alternative formats: 'full',
> 'brief', 'summary', 'Dublin Core', 'ebRIM' representations of the same
> thing.
> * the capabilities would provide a few canonical queries to get the
> client going ( a la OpenSearch? )
>    1) what's new
>    2) what are the new dataset
>    3) what are the new services
>    4) what's new published by X
>
> * capabilities doesn't provide URLs for operations, but for
> "collections"
>     GetRecords => Records
>     DescribeRecord => Schemas
>     GetRecordById => Records
>     GetDomain => Domains
>     GetCapabilities => Capabilities
>   ( just a name change, but it puts you in a different perspective )
>
> ...
>
> - Jason
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Ron Lake
> Sent: Wednesday, October 10, 2007 10:11 AM
> To: Sean Gillies; georss at lists.eogeo.org
> Subject: Re: [georss] [Mass-Market-GEO] OpenSearch Geo - Feedback
>
> Hi Sean:
>
> Thanks for the response.  That is helpful.  I agree that OGC stuff got
> started in the DOM/CORBA days - however all of the services that start
> with the letter W (e.g. WFS, WMS, WRS etc) were conceived in the post
> CORBA/DCOM era.  I would agree that there is some unstated flavor of DCP
> independence in the discussion as of course there is in WSDL (which you
> may feel is un-web like?) - I don't think there is much discussion
> explicit or implicit of OGC services over anything but IP networks - so
> the transports are really down to HTTP, SMTP at most.  I would NOT say
> that OGC services are intended to be RPC-like, nor would I say that they
> necessarily assume high availability nor minimal latency - quite the
> contrary.  Of course the web is infinitely more reliable and latencies
> are often quite minimal compared to the situation in the 90's.
>
> You say that in the web " hypertext as the engine of application state"
> - what do you mean by that?
>
> R
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Sean Gillies
> Sent: October 10, 2007 9:47 AM
> To: georss at lists.eogeo.org
> Subject: Re: [georss] [Mass-Market-GEO] OpenSearch Geo - Feedback
>
> Ron,
>
> I think Pete Lacey's recent post about new taxonomic terms might be
> handy here:
>
> http://wanderingbarque.com/nonintersecting/2007/10/08/towards-a-better-n
> etwork-programming-taxonomy/
>
> Services that are "for the web" are what Lacey calls network-oriented
> computing. These take into account the latency and unreliability of the
> web. They also embrace the constraints of the web: URLs, hypertext as
> the engine of application state, and a very limited set of semantics for
>
> accessing resources (GET, PUT, POST, DELETE).
>
> OGC services are what Lacey would call network-indepedent computing
> (NIC) in that they attempt to abstract away the network. They try to
> provide equivalent interfaces across a bunch of "DCP Types", of which
> HTTP is just one. It's also my understanding that the OGC services had
> their origins in the CORBA/DCOM mindset of the 90s, back when a lot of
> enterprises were still skeptical about the Web.
>
> Sean
>
> Ron Lake wrote:
>> Jason et al:
>>
>> One thing that would help in these discussions is to understand what
> one
>> means when we say "for the web".  Clearly all OGC services are
> intended
>> to function on the web and do to transactions, interact with one
> another
>> etc across the Internet.  Do you mean a particular suite of
> applications
>> "on the web" ?  How are these applications distinguished?
>>
>> Cheers
>>
>> Ron
>>
>> -----Original Message-----
>> From: georss-bounces at lists.eogeo.org
>> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Jason Cupp
>> Sent: October 10, 2007 3:52 AM
>> To: georss at lists.eogeo.org
>> Subject: Re: [georss] [Mass-Market-GEO] OpenSearch Geo - Feedback
>>
>> Mass-market WWW began as static HTML pages... now it's AJAX, HTTP
>> services, etc... it evolves. Our realization and use of the Web
> changes
>> overtime in re-re-re-interpretation of REST principals and whatever
>> comes next.
>>
>> CSW was just right for it's time. Is it wrong for the Web NOW? Maybe,
>> that's why we have working groups. Is OpenSearch right for the Web 20
>> years from now? Maybe... maybe not. Can discovering GIS resources work
>> using CSW. Yes. Should we try to gain greater appeal by adopting more
>> suitable (accepted today) technology? Most think so. Would OpenSearch
> do
>> the trick? That's what we're trying to figure out...
>>
>> -----Original Message-----
>> From: Charlie Savage [mailto:cfis at savagexi.com]
>> Sent: Tuesday, October 09, 2007 6:08 PM
>> To: Jason Cupp
>> Cc: georss at lists.eogeo.org
>> Subject: Re: [georss] [Mass-Market-GEO] OpenSearch Geo - Feedback
>>
>> Hi Jason,
>>
>>> Everyone is struggling to get a web search API just right for their
>>> users;  CSW suffers the same way that all OGC services do in the
>> growing
>>> REST spotlight. For -which- web at -which- time, a moving target,
>> until
>>> people start getting real work done on top of it.
>>
>> Let me cordially disagree with your comment about the web.  I only see
>
>> one web - what other web are you seeing?
>>
>> Also, I'm not sure what you mean by -which- time?  And I'm sure I
> don't
>> understand your comment about "start getting real work done on top of
>> it."  On top of the web?  Really?
>>
>> Charlie
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>