[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] Re: indirect handles actually implemented?
Hi Christophe:
> Note that this is only here because the registry service is not yet
> available and we needed to have a
> no service rendering capability.
...
> This is what the registry service will provide.
Thanks for sharing your ideas on the type registry. Sounds like you have
lots of goodies planned.
One question must be: When? Can you give us any idea on the likely timeframe
when we might see some of these pieces being introduced?
For example, I note that in the 0.TYPE/URL record you have added the XML
description fairly recently (see below).
Btw, I must confess to not having understood your last comment about my
question on needing to qualify URL types:
> Agreed and the handle value type description, in the case of value by
> reference, separates the reference from the
> value type.
As an illustration the hdl:0.TYPE/URL?index=2 value suffers exactly this
problem. So the value is a URL, so what? What does that "mean"? That is,
what's at the end of the reference?
Cheers,
Tony
{
"comment" : "OpenHandle (JSON) - see http://openhandle.googlecode.com/";
,
"handle" : "hdl:0.TYPE/URL" ,
"handleValues" : [
{
...
} ,
{
...
} ,
{
"index" : "2" ,
"type" : "URL" ,
"data" : "http://132.151.9.170/URL.xml"; ,
"permission" : "1110" ,
"ttl" : "+86400" ,
"timestamp" : "Fri Apr 18 20:29:29 BST 2008" ,
"reference" : []
}
]
}
On 6/5/08 16:44, "Christophe Blanchi" <cblanchi@cnri.reston.va.us> wrote:
>
> 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
>>
>>
>
********************************************************************************
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