On Jul 15, 2007, at 6:58 AM, Carole Goble wrote:
Alan
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?)
and the disadvantages? Lets not forget some basic rigour here.
Other than rebuilding everything from scratch. Again.
Fair enough. I think there will be some pain involved no matter what
the solution is, certainly on the side of current LSID users if we
choose not to use them universally, and otherwise on the side of the
clients who have not yet adopted them.
I do think that it it is possible to arrange things in such a way as
to minimize the impact to current LSID users -- there's been some
though even in this design to doing so - and probably more can be
done along the lines of the "batch" adaptations that provide
alternate mechanisms once the basics are in place. I *think* it may
simply be matter of making the purl redirect to the LSID resolver,
and generating some boilerplate RDF that lets other SW agents be
aware of the web service available "metadata".
Much of the rest of my proposal was either reusing other "standards",
such as 303, and making explicit some agreements that we would need
to make things predictable, that aren't currently specified in the
LSID spec (such as agreement on the format and some minimal contents
of the "metadata").
I also want to clarify that I don't mean to say that there isn't a
place for web services on the semantic web. But I did have
conversations with several people including you, who indicated that
they were burdonsome *in the specific case of id resolution* and
that, compared to other features of the spec - particularly location
independence - it might even be a benefit to dispense with them.
Thanks for saying something,
Alan
