Re: 303 +1, WSDL -1

Well... I apologize in advance, but I'm going to be *insultingly* blunt  
because I'm quite honestly losing interest in this seemingly pre-destined  
discussion...

"blinkers, are a piece of equipment used on a horse's face that restrict  
the horse's vision. They usually compose of leather or plastic cups that  
are places on either side of the eye, so that the horse can not see to his  
sides. Many racehorse trainers believe this keeps the horse focused on  
what is in front of him, encouraging him to pay attention to the race  
rather than other distractions, such as crowds"  
(http://en.wikipedia.org/wiki/Blinders)

WSDL is a widely accepted W3C spec that is becoming increasingly accepted  
worldwide (and is, generally, automatically generated based on your  
interface, so requires little or no manual construction), and which solves  
a problem that we *know without any doubt* URLs cannot solve.  I really  
don't see an advantage in trying to ignore them, circumvent them, or  
otherwise relegate them to a secondary lookup, in the base spec for the  
Semantic Web, when we know that we are going to have to deal with them at  
some point (and in fact, they are currently MORE POPULAR than RDF itself,  
according to Google Trends:  
http://www.google.com/trends?q=WSDL%2C+RDF&ctab=0&geo=all&date=all&sort=0

I really don't see the point in trying to build the Semantic Web by  
specifically avoiding acknowledgement of one of the most popular trends on  
the Web, when we already know that the vast majority of information we  
need to access as bioinformaticians is available through web forms or web  
services!

I'm sorry for being rude and disrespectful - I'm honestly quite  
embarrassed to be saying these things so harshly -  but I think this  
discussion has started to become a singularity around a pre-contrived  
end-point, rather than a discussion of what the Web (and the Semantic Web)  
really is/can be!

WSDL -1 if you wish, but that puts you in opposition to the majority of  
the world, where WSDL (thanks to Ajax) is finally starting to make it's  
mark!

Again, I apologize for being disrespectful and rude... it really isn't  
personal and I feel truly awful about writing this so harshly!  I'm just  
losing patience with a discussion that doesn't seem to be a discussion,  
but rather a shoe-horn into a pre-destined end point.

You are all free to crucify me the next time one of my grants comes to you  
for review ;-)

M




On Fri, 13 Jul 2007 20:19:41 -0700, Alan Ruttenberg  
<alanruttenberg@gmail.com> wrote:

>
>
> On Jul 13, 2007, at 12:20 AM, Mark Wilkinson wrote:
>
>
>>>> What worries me about the 303 solution (other than that we are not  
>>>> using it for
>>>> it's primary purpose [1]) is that the redirection can only be to a  
>>>> *single* resource, specified in the Location header.
>>
>>> On Thu, 12 Jul 2007 03:57:34 -0700, Jonathan Rees  
>>> <jonathan.rees@gmail.com> wrote:
>>> If this is an important functionality then it can be provided in a
>>> variety of ways - a mere matter of programming. LSID resolver happens
>>> to be the only way that comes ready made. But the functionality
>>> doesn't need to be tied to the use of LSIDs.
>>
>> If there is an alternative solution that provides the same  
>> functionality, and that can be applied universally to all existing URIs  
>> (URLs), then I'm all for it!  To be honest, this is my *primary*  
>> objection to moving to a URL solution vs an LSID solution... if you can  
>> solve that problem, then I am *almost* in the URL camp.
>
> Here is an alternative:
>
> Problem statement:
>
> Enable third parties to register the fact that they have additional  
> statements to provide about something that a URI denotes, in such a way  
> as to make it easy for anyone to discover this fact. Do this in a way  
> which requires minimal coordination (ideally none) between the minter of  
> the original URI, the provider of the additional statements, and the  
> consumer of all the statements.
>
> Solution:
>
> For a given URI http://a.b/c/d/e, construct a new URI  http:// 
> purl.org/about/a.b/c/d/e
>
> Configure the purl server so that http://purl.org/provide-about/a.b/c/ 
> d/e redirects to something akin to a structured wiki page or a REST  
> service (let us assume for the moment that whoever currently provides  
> the LSID WSDL that contains this information currently is the provider  
> of this service).
>
> This page may be edited (manually or programmatically) to include a  
> description (suitable for a machine to understand) of how to access the  
> resource and what sort of resource it is, and perhaps some additional  
> useful information (what predicates does the resource provide). This  
> information rendered as RDF using a standard vocabulary and saved.
>
> Configure the purl server so that http://purl.org/about/a.b/c/d/e  
> retrieves the RDF that was constructed (or a 404 if there is none).  
> Semantic web agents then interpret this RDF and go fetch what they want  
> or need.
>
> We all agree that 303s redirect to a human readable html document, that  
> this document uses a REL link to an RDF document that says what the  
> provider wishes to say and that the RDF also states that http:// 
> purl.org/about/a.b/c/d/e may have more information. (suitable shortcuts  
> are provided to make bulk retrievals more efficient - we've already  
> discussed such mechanisms)
>
> This can be done now, with effort analogous to what is being done with  
> LSIDS. Let me point out some obvious advantages: 1) No requirement to  
> use web services (though web services *could* be described as ways of  
> accessing further statements using this scheme) 2) Requires *less*  
> manual intervention than is currently required to maintain the WSDL. 3)  
> Re-uses purl, which is based on HTTP, which everyone knows how to use  
> already 4) Makes clear that the description of these additional  
> resources for statements are to be in RDF, and requires that one  
> advertises what to expect if you go to the resource (will you get an RDF  
> document, a SPARQL endpoint, a Web service set of methods?)
>
> ---
>
> With a bit more effort expended on extending the purl server code we can  
> get some more leverage - we enhance it so that retrieving http:// 
> purl.org/about/a.b/c/d/e actually merges the RDF result of retrieving  
> each of http://purl.org/about*/a.b/
> http://purl.org/about*/a.b/c
> http://purl.org/about*/a.b/c/d
> http://purl.org/about/a.b/c/d/e
>
> Where the about* top level domain indicates that the information about  
> covers all URIs that start with the indicated path.
>
> In this way different providers can note that they have additional  
> statements about URIs located in varying amounts of namespace.
>
> With some coordination among us, we could even decide to dedicate a  
> server to hosting the whole mess of this information (I don't expect  
> that it needs too large a resource) so as to make the service more  
> efficient in answering queried, and making it easy to provide, to  
> whoever wishes, a snapshot that they can host themselves.
>
> ---
>
> May I now count you among those *almost* in the URL camp? ;-)
>
> -Alan
>
>
>
>

Received on Sunday, 15 July 2007 05:31:06 UTC