Dear Jon,
Thank you for the interesting comments. Actually our paper was
conceived to raise and discuss similar points. In fact, these
subjects are quite open and under investigation.
Let me start answering to your last point; the answers to your other
comments will follow in another email.
4) "While OWS POX binding is not a RESTful implementation it is still
implicitly resource-oriented since it is based on a uniform interface
(getSomething) on different resources (capabilities, descriptions,
coverages, features, etc.)." I see what you are saying here, but I
still see OWS as being query-oriented (the query is the important part
of the protocol, not the data payload). Queries are not CRUD
operations in the usual sense. Yes, OWS is based on access to
resources but in fact there are an *infinite* number of possible
resources (coverage subsets, feature subsets, etc). As I said in a
previous email the REST approach might improve the URI syntax for OWS
requests but I'm still not convinced of its value otherwise: I still
worry that it makes little sense - and provides little real value - to
try to converge the REST and OWS worlds.
Frankly speaking, I didn't want to state that the REST approach is
the "best" way to implement OWS. We started considering some REST
successful stories and we wanted to understand the benefits and
limitations for Geo-information Web-based infrastructures. In order
to explore this possibility there exists the need to define a
complete and realistic REST framework for geo-information. This was
the main motivation for our document.
Said that, I would like to answer to your important point: the query
nature of OWS and the infinite number of resources.
A valuable case of REST approach is the SQL. In fact the SQL commands
implement the CRUD functionalities, the FROM-WHERE clauses expresses
unique resource IDs. SQL proved to be a very successful technology.
It was conceived to implement access to information stored in DB.
Actually SQL stands for Structured Query Language, thus, the query
aspect was central in the SQL definition.
You may use the SQL clauses to select *infinite* number of possible
resources (i.e. set of tuples from one or more joined tables/views).
SQL commands and keywords are relative few; command semantic is
"simple". In other words, they define a quite fix and "general"
interface protocol.
Our point is whether it is possible to use the REST Web technologies
for Geodata infrastructures as SQL technology has been used for DB
infrastructures.
Regards,
--Stefano
