[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-info] Re: indirect handles actually implemented?


Hi Tony,


Do you have a good use case in mind?

Yes. It's called the Web. ;) (I note you asked that question twice.)

Seriously, though. I think it could be useful to think beyond XML schema as
such. Schema is effectively a cul-de-sac. A road to nowhere. Main usage for
schema is as a data packaging mechanism, i.e. a means of marshalling related
data items using markup. It can provide for a local semantics - but not one
that wants interoperate with the wider world.
I agree with your assessment of schema as a cul-de-sac but it is important to remember what it is that
we are using it for in the context of the handle value type registry.

The schema is used exactly as you mention it: "a data packaging mechanism". In our case especially,
we want to have a clear description of how one defines a handle value type and we want to be able
to enforce a minimum set of descriptions and references to standard. We also want to make it as accessible
to as wide an audience as we can for a greater uptake both in feasibility and use of "well agreed" to standards.

From the acquisition of the "data package", the registry will validate the description information in the
package and enforce certain data level "business rules". This information makes its way into a search engine
which will index the various fields to make them text and field searchable and accessible.

The handle value type registry will be a service and as such will have an extensible set of service interfaces. Some service interfaces will be for human consumption (search and retrieve) while others will be for machines.
I can imagine that as the need arise, a service that generates RDF will not be very difficult to build.

At this point, the registry query lingua franca will be the OpenURL standard (and not only the URL serialization) with
handle defined services.
If it must be schema then let it carry an embedded RDF (RDFa) or at the
least be GRDDL-able.
We can easily put out a service interface that will generate GRDDL but since the registry is a service,
might as well just request whatever RDF you want provided we give you the service for it. 
Other folks are beginning to embrace the RDF data model. Consider even the
digital library community where the OAI folks have moved (are moving) from
PMH with bespoke XML schema to ORE which is defined as an RDF profile. (Yes,
the main serialization uses Atom but that's essentially a "compromise
solution". At least they provide for a GRDDL transform as well.)

Consider the current impetus behind the whole Linked Data effort, which is
seeking to rejig the semantic web as a nuts-and-bolts data web initiative
rather than some whacky AI vision. And doing demonstrably well within that
perspective.

Or consider even mainstream efforts like Yahoo! Search which are now
intending to index semantic markup, and sites like Digg which are including
semantic markup.
Using XML schema for semantic disclosure could be seen to be somewhat
limiting. You say:

"We dereference the XML definition in a URL field to be able to leverage
the current proxy URL redirection functionality to display the XSLT
rendered XML description of the URL type definition."
Note that this is only here because the registry service is not yet available and we needed to have a
no service rendering capability.
I'd really rather see a description accessible to machines than a pretty
printed version for human consumption. But I may be rather lazy. I'd prefer
not to have to think too much. Let the machines do the walking between
applications.
This is what the registry service will provide.
I do think it's a very positive step to use (require?) handles for handle
types. (From there it is one small step to a URI. Of course, there are those
who will argue that it's the wrong flavour of URI but so what. There's more
to URI than HTTP.)
I can imagine that the registry will contain non handle handle value type for legacy and compatibility issues.
It is possible that all non handle handle value type be assigned an handle alias at registration thereby allowing either
handle value type identifier to be used.

I'm still unsure what the *discovery* mechanism for handle types is, or will
be. Would there be a registered listing somewhere or a means of querying the
type registries?
The type registry is a service that has a full blown search engine interface. Text or any specific fields can be searched.
The results can be displayed in any format that ends up being needed: an XML list of types description, a HTML list of hits, an RDF graph, and RSS feed. The OpenURL query can specify the target format by handle ID so as long as that handle ID maps to a rendering implementation, the type registry will generate it.
Anyhow, look forward to seeing how this opens up. I have particular
interests in assigning some meaningful types. For example, I would like to
be able to type a reference (URL) to a type of document as being of document
type rather than URL. URL, here, being just the reference mechanism not the
underlying semantic type. Otherwise, if we are constrained from a handle
point of view to a limited number of type primitives (e.g. URL) then we'll
need to be able to bundle the primitives together with qualifiers (e.g.
URL=http://..., DESC=MODS, say) in order to ascribe a proper semantics. But
what it really needs is a proper dose of RDF to keep it simple.
Agreed and the handle value type description, in the case of value by reference, separates the reference from the
value type.


Thanks for the discussion,

Christophe

Hi Tony,
The use of OpenURL will be especially valuable as a generic syntax for
expressing queries to handles
that have handle types registered in the handle type registry that we
are in the process of developing
at the moment.
Is there (or will there be) any means of querying for a list of registered
handle types? As I understand from the Tech Manual (v6.2) the following
non-admin types are currently defined:

* URL
* EMAIL
* DESC
Yes, the registry will provide the means to list types. This handle
type registry will also provide you with the ability
to search for types based on field defined within the XML schema for the
handle value type description that we are internally reviewing at the
moment.
Of course, one does wonder where (or if) application specific types will be
registered, e.g. the DOI app which uses this control type regularly:

* 700050

and a few sundry types for the multiple resolution pilot.
The type registry being developed is designed to allow for external type
registration.  It is possible
that we might start with a two tiered registry with "industry approved"
types and "experimental" types
until we get a better picture of what and how many types will be
registered.   I can imagine a process
by which experimental types will migrate to industry approved types.

A couple of items worth mentioning.

    1) In the first version of the type registry, we will favor/require
using handles for identifying handle value
    types.
    We recognize that there will be legacy non handle value type names
but those will be handled in the
    handle value type XML definition using the alias and type versions
fields.

    An example is the URL type which is "defacto" mapped to 0.TYPE/URL.
This is not a practice that
    we wish to encourage. Note that the 0.TYPE prefix will be reserved
for handle system types only.
    eg. HS_ADMIN, HS_SERV and the likes.
    Other non handle system specific type, will use other naming
authority e.g. 10320/loc for the multiple URL
    location redirection type).

    2) Do handle value types have to have an existing handle in order to
be registered?   At the moment, we will
    probably require that to be the case.


We will also put some limitations on who can register handle value types
to make sure we do not populate the
registry with types from over eager type depositors :)!.  As we develop
a type registration policy, the registry
will be made open.

Also, will the type registry contain any machine readable information.
Currently the registered types seem to have HS_ADMIN and DESC fields, and
the URL type has a URL field referencing an XML document:

http://132.151.9.170/URL.xml
Yes and the registry will index all typed description to enable for type
searching. Dynamically generated OpenURLs or RDF could be generated from those
searches
if a use case presents itself.

Each handle value type handle will reference or contain an XML
description of itself.  That description
will contain machine readable/usable fields such as resolver proxy
addresses, service access points,
downloadable code etc.
The handle type XML schema is currently being developed and is being
reviewed internally before we open
it up for public comments.

And Tony ... only you would have noticed the existence of that type
definition :)!

The URL type is the first type definition that we are experimenting
with.  The XML contains a preliminary instance
of the handle value type XML schema.  Note that its contents will be
subject to changes and the schema itself will
evolve and currently contains other structures that are not apparent in
that instance.

As the URL type illustrates we have the old issue of in-line vs
by-reference for storing the XML definition.
We dereference the XML definition in a URL field to be able to leverage
the current proxy URL redirection functionality to display the XSLT
rendered XML description of the URL type definition.

Ultimately,the XML definition for a handle value type will be able to
reside in-line in in a 0.TBD.Prefix/HVTDesc
(final name TBD)  typed handle value.

Would be great to also see a pointer to some RDF, otherwise it's just
another markup document.
Do you have a good use case in mind?

Thanks,

Christophe
Cheers,

Tony


*****************************************************************************
*** DISCLAIMER: This e-mail is confidential and should not be used by anyone who
is
not the original intended recipient. If you have received this e-mail in
error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number
785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
*****************************************************************************
***



_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info



_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info