[Handle-info] Correction: OpenHandle: An RDF Serializer for Handle

["Hammond, Tony" <t.hammond@nature.com>]

Whoops!

RFC was wrong. Should be

http://www.ietf.org/rfc/rfc3651.txt

(Not 3151. Different thing entirely. ;)

Tony


------ Forwarded Message
From: <Hammond>, Tony <t.hammond@nature.com>
Date: Tue, 05 Feb 2008 15:44:05 +0000
To: <handle-info@cnri.reston.va.us>
Conversation: OpenHandle: An RDF Serializer for Handle
Subject: OpenHandle: An RDF Serializer for Handle

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:

    http://nascent.nature.com/openhandle/handle?id={handle}

e.g.

    http://nascent.nature.com/openhandle/handle?id=4263537/5029

The intent is to expose the complete handle record as RDF/XML to make it
more accessible to web applications, e.g. XUL datasources.

(Note: this work reprises an earlier implementation from several years ago,
although this time we're figuring to do it right. Terminology is better
aligned, and also use of rdf:Collection instead of earlier rdf:Bag.)

So, this is just an initial shot to see what folks think. Some questions:

    1. There are some obvious deficiencies, especially in dealing with
service handle types. Also we should add in a <references> field even when
it is null.

    2. At the moment the RDF/XML is more aligned with the Java code [2] than
with the RFC [1], especially in say treatment of permissions which is a
single field in the RFC (bitmask) but implemented as separate boolean fields
in the Java code - see below. Also <ttl> is a little more complex than
shoewn and we shouldn't have rendered the string in display form.

    I guess we should strictly align the RDF with the RFC.

    3. I would imagine we should add in datatyping - but since it's noisy
and may not be always required perhaps we should make that optional. Then
instead of something like

    <h:readValue>true</h:readValue>

one would have

    <h:readValue rdf:datatype=[xsd:boolean]>true</h:readValue>

(Here the [...] notation is just CURIE syntax, I think, to save my fingers
typing this.;)

    4. I've referenced other handles using URIs, specifically using "info:"
URIs, which means that one can refer to a secondary resource (e.g. "index",
"type", etc.) using the fragment identifier.

(Note: the fragment identifier is not part of the handle. A handle
represented in URI form needs to be %-encoded which means that any '#' char
occurring within the handle string would be %-encoded. A fragment in URI
terms allows one to refer to secondary resources. As such this seems to be a
legitimnate means to refer to a field, or set of fields, within a handle
record.)

info:hdl/0.NA/10.1000#index=200<

    5. Maybe we could allow for other parameters on the querystring, e.g.
datatyping, authoritative query, etc. Perhaps also allow for an alternative
RDF serialization, e.g. RDF/N3 which would really make the handle record
more open.

Anyhows, this is being put out there for feedback and we would genuinely
welcome any comments. We realize there are shortcomings at present but think
that the overall approach has some merit.

Cheers,

Tony


###

[1] http://www.ietf.org/rfc/rfc3151.txt

[2] HandleValue.java

public HandleValue(int index, byte type[], byte data[], byte ttlType, int
ttl, int timestamp, ValueReference references[], boolean adminRead, boolean
adminWrite, boolean publicRead, boolean publicWrite)
  {
    this.index = index;
    this.type = type;
    this.data = data;
    this.ttl = ttl;
    this.timestamp = timestamp;
    this.references = references;
    this.adminRead = adminRead;
    this.adminWrite = adminWrite;
    this.publicRead = publicRead;
    this.publicWrite = publicWrite;
  }

###



 

------ End of Forwarded Message


********************************************************************************   
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