[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] Re: indirect handles actually implemented?
Hi Christophe:
> 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.
If it must be schema then let it carry an embedded RDF (RDFa) or at the
least be GRDDL-able.
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."
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.
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'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?
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.
Cheers,
Tony
On 2/5/08 20:49, "Christophe Blanchi" <cblanchi@cnri.reston.va.us> wrote:
> 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