Hi,
> 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 may be mistaken, but isn't WSDL just an XML format? I don't see how
it solves a problem that URLs "cannot solve"...wouldn't the location
of "foo.wsdl" be best specified as a URL?
> in fact, they [WSDL] are currently MORE POPULAR than RDF itself,
according to Google Trends
But the appropriate comparison is to URLs, not RDF...and the
advantage of a URL is that there's tons of widely deployed,
lightweight technology for requesting data from a given URL (e.g. w/
a browser as well as Perl/Python/etc. libraries) and for setting up
web servers (e.g. Apache).
I don't understand why it should be necessary to develop a parallel
set of technologies (e.g. the Firefox LSID plugin, or HTTP proxies)
for resolving LSIDs, particularly when most (all?) of these tools
seem to be built on top of tools (such as Firefox) which can already
do URL resolution without downloading anything.
It would seem to me that the best way to get a reliable set of
canonical URIs is to get NCBI involved. As soon as NCBI published a
set of canonical URIs (e.g. for genes in Entrez Gene, compounds in
Pubchem, etc.) then everyone could use them with confidence. Reasons:
1) NCBI identifiers (even more so than EBI) are the de facto standard
and can be mapped to anything.
2) NCBI is well funded, has serious bandwidth, etc.
3) NCBI can be trusted to stick around for a long time and to
maintain/redirect old URLs, unlike a research lab or most companies.
4) In terms of registering new URIs, NCBI is already a standard
location for data submissions (w/ NCBI GEO, GAIN, etc.).
5) People already use NCBI to get other kinds of data, so getting RDF
data from them is not a serious paradigm shift.
Perhaps there's someone from NCBI on the list; if not, it would be
worthwhile to contact them. If NCBI adopted the standard that
beta.uniprot.org is using, with different suffixes for different
formats (as per Eric Jain's email):
http://beta.uniprot.org/uniprot/P12345
http://beta.uniprot.org/uniprot/P12345.xml
http://beta.uniprot.org/uniprot/P12345.rdf
http://beta.uniprot.org/uniprot/P12345.fasta
....then I think people would adopt it immediately, especially if they
kept it on their front page for a month (like they do with other new
services). Regarding the way UniProt is doing things, I think it was
a particularly good design decision to have the de-facto suffix be
HTML, so that you can get a sense of what the URI represents by
looking at it in a browser.
Also, from Matthias' recent email:
> You should not try to pack ANY information about the 'resolution'
of a Semantic Web resource into its URI, quite to the contrary. Make
it as meaningless and generic as possible, in the best case it should
just be a large random alphanumeric string, e.g.
tag:uri:a938fjhsdcHSDu39. If all URIs look like this, nobody will be
detered from re-using a URI just because of how it looks.
I don't know if this is such a good idea -- when debugging, you want
to have some information about what the URIs represent (e.g. the
"http://beta.uniprot.org/uniprot/"; prefix tells you that you're
looking at a UniProt protein with the given ID number). If URIs are
just alphanumeric strings, you need to constantly be doing lookups to
remind yourself of what a particular object means.
--B
--
Balaji S. Srinivasan, Ph.D.
Stanford University
Lecturer, Depts. of Statistics and Computer Science
318 Campus Drive, Clark Center S251
(650) 380-0695
[EMAIL PROTECTED]
http://jinome.stanford.edu
On Jul 14, 2007, at 10:30 PM, Mark Wilkinson wrote:
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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
