Hi Pete,
> OK... but just to confirm: that (non-en-US) data _is_ already
> being made
> available as RDF/XML through the registry query API? Is that right
> please?
>
> i.e. my application can issue a query (using SOAP and using one of the
> registry API methods) that says, "Give me descriptions of all
> the stuff
> that isDefinedBy http://purl.org/dc/elements/1.1/ and give me the
> literals in French" and get back some (SOAP-wrapped) RDF/XML. (In
> practice it may require a couple of queries but basically I
> can get the
> data?)
What you are calling the registry query API is what I call the registry
application interface. This interface currently supports 8 different
requests. These are explained here:
http://dublincore.org/dcregistry/install.html#S3.3 (human readable) and
here: http://dublincore.org/services/inspection.wsil (machine readable).
The itemDetail service provides this level of information, in RDF, in a
specific language, and for a specific term. We haven't deployed a service
that will do this for all terms. However, (I am a bit hesitant to mention
this) there is a termUpdates service that will return (in RDF) all
information about terms that have been added or modified since a specific
date, and in a specified language. :)
The 8 services are what comes standard with the registry. Are they enough?
I don't know. Probably not, but I think it is important that we get some
practical experience and feedback before creating new ones. Of course
distributed sites (like UKOLN) can always add their own. This is part of
the design and is fairly easy to do. For example, the UKOLN registry
includes some application profile data (a UKOLN extension to the base
registry). This info is available now (to humans) via the Web interface.
Why not also make it available via the application interface?
> > In the meantime there are (at
> > least) two options available for getting the translaitons -
> > the Web (humnan) interface and the application interface.
> > BTW - you don't need to know anything about SOAP, to use the
> > application interface.
>
> I wasn't sure exactly what you meant by the "application
> interface". Did
> you mean http://wip.dublincore.org/translate/index.html
No. That is the translate tool. The application interface is how
applications (i.e., other registries, metadata tools, etc.) can access
registry information.
> Just to clarify, I'm talking about access for a software tool, rather
> than a human reader.
>
> So e.g. doing a straight HTTP GET
> http://purl.org/dc/elements/1.1/ will
> return to my application the "en-US" data as RDF/XML, but to get e.g.
> the description of dc:title with the literals in French, my
> application
> has to issue requests through the registry API over SOAP.
> That's right,
> isn't it?
Don't get hungup on the fact that the services are deployed using SOAP (Axis
actually). They are deployed as Web servies, and as such, that level of
detail is hidden from you. There are a number of (free) client code
generators that will automatically create the code you need to access the
services. Simply imbed this auto-generated code into your application.
I've tested this (on a number of platforms, languages, etc.) and it works.
Please let me know if you need help getting started with this.
Regards... harry
> (Also, didn't you publish a (human-readable) description of the API
> methods? I can't seem to find it, but I'm sure I read
> something when you
> first made them available?)
>
> Thanks
>
> Pete
>
|