Web Services
-
-
Along with the idea of a web page for data download/upload, a link to a human-readable page on Web services associated with the database would also be useful. This is often a very different thing from simple download links. Future domain-centric types for databases may include specific URL properties to retrieve something like a capabilities response for certain types of databases.
-
This sounds different than the Database website type I've associated with databases, which conceptually is the online GUI homepage but in practice has been a little broader than that. It also sounds different than the website category of Web service, which appears to focus on machine readable services.
The easiest thing to do is to add a couple URI properties to Database for human readable and machine readable web services and then migrate any existing web service topics over. However, the property names should do a decent job of reflecting differences in machine readable and human readable web services as well as differentiating them from "upload" and "download", or revising the definitions of those existing properties. Do you have any suggestions other than "Human readable web service", "Machine readable web service", "Upload" and "Download"? Also, it sounds like there may be multiple web services associated with a database so the new web services properties should not be limited to a single value, correct?
-
Well, the two topics currently listed under the Web service category do seem to be what I envisioned here: a human readable explanation/directory of available services. USGS Water Services points to a page from the USGS NWIS program on available Web service connections to that database. The Amazon Web Services topic points at a page with a much different idea about "Web services": commercial hosting and other professional services in the Web realm. The definition for the Web Services Website type comes from a very broad wikipedia article, so I guess it follows that we would end up with very different things there.
I would consider the "machine-readable" idea being something more like a WSDL or getCapabilities type of reference that would be a predictable, standards-based method on the other end of a URI. So, perhaps we need to distinguish "Web Service" in the two examples we have under the current Web Service type and use/add other specific types along the lines of application/wsdl+xml media type to contain predictable references to services.
The end goal from my perspective is to allow a conceptual topic about a database like the "National Water Information System" to contain links to both human- and maching-readable references for "technical" Web services that expose how those underlying data can be interacted with. If we've got something like one or more application/wsdl+xml references for a database record, then we can write applications that can interact directly with those Web services and give a user a seamless experience from discovering about a database to interacting with its data.
So, the "Machine readable web service" idea needs to be distinguished between types of standardized Web service interfaces. We also need to come up with a way of distinguishing between the Amazon and USGS examples of a human readable link reference, which are both currently using perfectly legitamate derivations of the term Web Service.
-
I think I understand what you want but I'm not familiar with the protocols. It sounds like we need to add some URI properties to the Database type for each standards-based methods of file transfer. That way, code can be written so that a machine knows, based on the property name, what protocol is used at the other end of the URI. Correct?
I've added a new URI property for WSDL web services to the Database schema. Let me know if this will meet your needs. If so, what other file transfer protocols should be added as web service URI properties to Database?
As for the human readable web services, I haven't really seen any standards. The current URI properties (e.g., upload, download) probably fit most needs but I'm happy to revise their names, descriptions, etc.
-
Shouldn't there be discoverable directories with this stuff? If you really want to hand maintain a shadow directory, you'll need in addition to WSDL, at least RDF/SPARQL and home grown RESTful protocols like http://www.freebase.com/view/freebase/metaweb_api_service
Some other directories which might give you an idea of the types of things that people want to see:
- http://www.programmableweb.com/api/freebase
- http://www.apifinder.com/APIFinder/APIDisplay/29495
- The Linked Open Data site has a directory of RDF sources (including Freebase) http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets
-