[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] OpenHandle: An RDF Serializer for Handle
Hi Konstantin:
Many thanks for sharing your XML schemas. For now, I have just printed them
out and only had a cursory glance over them.
I would make a couple initial points though:
1. As I replied to Giridhar I do see value in exposing the *complete* handle
record, not just those bits that look to be of present interest. Though
initially it involves more work, I believe that in the long run there will
be a saving as there are no exceptions to manage or to care about. No hidden
surprises. (Rather like Ruby's POLS mantra - "Principle of Least Surprise".)
The whole record should be exposed - out in the open for whatever
application purpose: admin or user-defined.
2. So, given the above, I note that your instances are very
<type>/<data>-centric with <index> and <timestamp> attributes. I have opted
to be neutral wrt the handle value fields. This also means that the other
fields - <ttl>, <permssion>, <reference> - also get a look in.
3. Also mentioned in the reply to Giridhar, I only recognize the pre-defined
HS_* types in the RFC. The user-defined types (URL, URN, EMAIL, ...) are not
part of the public spec.
4. An extension of xsd native datatypes would be interesting as I indicated
in the earlier post wrt bitmasks. Such a datatype library could be
referenced by many serializations: RDF/XML, RDF/N3, JSON, XSD, RLX-NG, ...
My concern was how to manage that. If it were registered somewhere centrally
it could be referenced. Otherwise to travel along with the schema it would
have to be what? In a zip file with the schema? In an XMP packet inside the
schema?? So, I guess I would want to examine what real need or advantage
there would be to extend the native xsd datatypes. Or are the native
datatypes sufficient?
Anyhows, I only just had a quick look and would need to reflect some more on
this. The reason for opting for an RDF data model to expose the handle
record is that it simplifies the mixing of this data with other data
sources. Not something that XML is really set up for. Namespaces gives one a
means of compartmentalizing (or modularizing) the data - not of merging it.
Cheers,
Tony
------ Forwarded Message
> From: Konstantin Rekk <konstantin.rekk@gbv.de>
> Organization: GBV VZG
> Date: Sat, 09 Feb 2008 03:02:17 +0100
> To: "Hammond, Tony" <t.hammond@nature.com>
> Cc: <handle-info@cnri.reston.va.us>
> Subject: Re: [Handle-info] OpenHandle: An RDF Serializer for Handle
>
> Hi Tony, hi all,
>
> thank you for starting this discussion and sharing your approach to this
> issue.
>
> Since last year I have been working on a REST-version of a webservice to
> access the handle system. Motivated by the current discussion I finally
> pushed it to version 0.1 which I would regard rather as a proof of
> concept and a contribution to this discussion. This schema can be used
> as a starting point to design a custom REST interface to the handle
> system.
>
> Designing the schema I have had Java's JAXB data binding in mind and the
> possibility to extend handle data types especially using xml-formatted
> data in handle values data section. I also wanted to be the
> representation of handle values in instance documents human readable so
> that clients can easily deal with the semantics of handles.
> (no bits and bytes ;-) ) .
>
> Have a look at
>
> http://www.rekk.de/bloggy/wp-content/uploads/2008/02/handle_schema.zip
>
> The schema files are commented und you will also find an example which
> demonstrates custom datatypes usage.
>
> May be we could join our efforts.
>
> Please feel free to express feedback and criticism.
>
> Best!
>
> Konstantin
>
> On Tue, 2008-02-05 at 15:44 +0000, Hammond, Tony wrote:
>> Hi All:
>>
>> We would be interested to get some feedback from this list about a test
>> handle serializer facility we've set up here - OpenHandle:
>
------ End of Forwarded Message
On 9/2/08 02:02, "Konstantin Rekk" <konstantin.rekk@gbv.de> wrote:
> Hi Tony, hi all,
>
> thank you for starting this discussion and sharing your approach to this
> issue.
>
> Since last year I have been working on a REST-version of a webservice to
> access the handle system. Motivated by the current discussion I finally
> pushed it to version 0.1 which I would regard rather as a proof of
> concept and a contribution to this discussion. This schema can be used
> as a starting point to design a custom REST interface to the handle
> system.
>
> Designing the schema I have had Java's JAXB data binding in mind and the
> possibility to extend handle data types especially using xml-formatted
> data in handle values data section. I also wanted to be the
> representation of handle values in instance documents human readable so
> that clients can easily deal with the semantics of handles.
> (no bits and bytes ;-) ) .
>
> Have a look at
>
> http://www.rekk.de/bloggy/wp-content/uploads/2008/02/handle_schema.zip
>
> The schema files are commented und you will also find an example which
> demonstrates custom datatypes usage.
>
> May be we could join our efforts.
>
> Please feel free to express feedback and criticism.
>
> Best!
>
> Konstantin
>
> On Tue, 2008-02-05 at 15:44 +0000, Hammond, Tony wrote:
>> Hi All:
>>
>> We would be interested to get some feedback from this list about a test
>> handle serializer facility we've set up here - OpenHandle:
>
********************************************************************************
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