[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] OpenHandle: Bitmask or Boolean?
Tony,
The OpenHandle serializer seems like a good gateway service to
applications/service providers that do not understand (or trying to
bypass) handle protocol. I have couple of questions on the serialization
which pretty much goes back to the use case and the audience of this
effort. It is highly likely that I mis-understood the background for
starting this effort.
(1) The Handle System specific handle types such as HS_SITE, HS_VLIST,
HS_ADMIN (HS_NAMESPACE is missing in your list) etc are specific to
handle protocol. These types are integral to the handle system
functionality. There is very little value to third party applications as
far as these types are concerned, as these types are processed during
the resolution of the handle and retains zero-information to the
applications. The OpenHandle serialization verbosely (for lack of
terms) describes these types. So the question I have is: which
applications need these protocol specific information. I understand that
the serialization tried to define the handle record from the scratch.
But, instead of providing RDF serialization to type/data pairs and
leaving out the semantics of what goes into the data part to third party
applications, the OpenHandle serializer (the draft version) seemed like
trying to define a RDF packet for handle (transport) protocol. I would
have understood if the expansion of data (in type/data pairs) is aimed
for user-defined types for your specific project. But since the
OpenHandle serializer seemed to be a generic effort, the data should be
described to be a byte array (however encoded) with encoding type as a
separate attribute. Also, providing a text version for this data might
be useful. In this text, you could display a text version of HS_SITE,
HS_VLIST etc, just so that people/applications understand what it means.
(2) In the set of attributes (e.g. index, type, data, ... , reference)
defining a handle value, the syntax you have chosen for the 'reference'
is questionable. Quoting your comment here:
"A handle reference refers to another handle value in terms
of a UTF8-string and a 4-byte integer (where the UTF8-string is the
handle name and the integer is the value index). For convenience a
handle reference is implemented as a URI-ref using the "info:" URI
scheme, where the handle value index is referenced in the fragment
identifier. For example, a handle reference to the handle
"10.1045/may99-payette" with index value "100" will be implemented
as the URI "info:hdl/10.1045/may99-payette#index=100".
Any series of characters following the syntax: info:hdl/<identifier> is
a URI provided the identifier is indeed a handle identifier and complies
with URI syntax. In your comment,
info:hdl/10.1045/may99-payette#index=100 is pointing to index '100' of
the handle '10.1045/may-99-payette'. But, this contradicts with the
info:hdl syntax. Following the syntax the entire string
10.1045/may99-payetter#index=100 is a handle. (I still need to verify
this with other folks here at CNRI, but it looks like the syntax format
you chose may result in a semantic collision.)
Thanks
Giridhar
Hammond, Tony wrote:
Hi:
Am still plugging away at the RDF schema for our OpenHandle serializer and
posted a new version today at
http://nurture.nature.com/tony/schemas/handle.rdfs
Instances would look as the RDF/N3 copied below for <info:hdl/10101/nature>.
(I've posted this together with RDF/XML for the polyglot along with the
schema:
http://nurture.nature.com/tony/schemas/10101_nature_new.n3
http://nurture.nature.com/tony/schemas/10101_nature_new.rdf [.rdf.xml]
.)
I've been looking at a couple principles in developing the schema:
0. As far as possible I've copied language directly from the RFC. In
some cases I've needed to patch.
1. Used camelcase for names (as usual practice in RDF) - properties
start lowercase, e.g. h:handleValues, and classes start uppercase, e.g.
h:HandleValue.
(Only exceptions to class names are the pre-defined data types and acronyms,
e.g. h:HS_ADMIN, h:HS_SITE, ..., and h:TTL.)
2. As far as possible I've used names per the RFC with a couple
exceptions:
a) Because the RDF data model uses a property/class breakout some new
terms need to be introduced (especially classes to manage constraints)
b) To abide by #1 above I sidestepped some of the capitalizations in the
RFC, e.g.
h:adminRead "true" for ADMIN_READ permission, etc.
h:addAdmin "true" for Add_Admin permission, etc.
(and h:listHandle "true" for the LIST_Handle permission)
3. Datatypes. I've tried to abide by native xsd datatypes (see schema
property ranges - and will add datatypes as option to RDF record). So far,
I've used these:
&xsd;nonNegativeInteger
&xsd;string
&xsd;boolean
&xsd;token
&xsd;anyURI
&xsd;unsignedByte
&xsd;dateTime
Still a moving target - especially need to deal with "data" field to
express arbitrary data correctly in RDF/XML.
4. With regard to #3 I thought it would be legitimate to use
xsd:dataTime (ISO 8601 format) for timestamps (rather than integer number of
seconds, although stand to be corrected if this unwise).
Also, for the permissions bitmasks I elected to use booleans, similar to
the Java code, e.g.
boolean adminRead = true;
<r:Property r:ID="adminRead">
<s:label>adminRead</s:label>
<s:comment>Property attributing a "ADMIN_READ" permission. This
permission allows the handle value to be read by any handle
administrator with AUTHORITIVE_READ privilege.</s:comment>
<s:domain r:resource="#Permission"/>
<s:range r:resource="&xsd;boolean"/>
</r:Property>
Strictly, and following the RFC, one could define an applied bitmask xsd
datatype, e.g. something like
<xsd:simpleType>
<xsd:restriction base="xsd:unsignedByte">
<xsd:enumeration value="#x01"/>
<xsd:enumeration value="#x02"/>
<xsd:enumeration value="#x04"/>
<xsd:enumeration value="#x08"/>
<xsd:enumeration value="#x10"/>
<xsd:enumeration value="#x20"/>
</xsd:restriction>
</xsd:simpleType>
but I think that would add unnecessary complexity (as well as being
difficult to manage and reference the definitions).
Anyway, would welcome any feedback on particulars or in general.
Cheers,
Tony
####
#Processed by Id: cwm.py,v 1.197 2007/12/13 15:38:39 syosi Exp
# using base file:///Users/tony/My
Developer/openhandle/rdfs/10101_nature_new.rdf.xml
# Notation3 generation by
# notation3.py,v 1.200 2007/12/11 21:18:08 syosi Exp
# Base was: file:///Users/tony/My
Developer/openhandle/rdfs/10101_nature_new.rdf.xml
@prefix : <http://nascent.nature.com/schemas/rdf/handle#> .
@prefix r: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<info:hdl/10101/nature> a :Handle;
:handleValues (
[
a :HandleValue;
:data [
a :HS_ADMIN;
:adminPermission [
a :AdminPermission;
:addAdmin "true";
:addHandle "true";
:addNA "true";
:addValue "true";
:authorizedRead "true";
:deleteHandle "true";
:deleteNA "true";
:deleteValue "true";
:listHandle "true";
:listNA "???";
:modifyAdmin "true";
:modifyValue "true";
:removeAdmin "true" ];
:adminRef <info:hdl/0.NA/10101#index=200> ];
:index "100";
:permission [
a :Permission;
:adminRead "true";
:adminWrite "true";
:publicRead "true";
:publicWrite "false" ];
:reference [
a :Reference;
:referenceCount "0";
r:rest () ];
:timestamp "2007-02-28T17:08:15Z";
:ttl [
a :TTL;
:ttlType "relative";
:ttlValue "86400" ];
:type "HS_ADMIN" ]
[
a :HandleValue;
:data <http://www.nature.com/>;
:index "1";
:permission [
a :Permission;
:adminRead "true";
:adminWrite "true";
:publicRead "true";
:publicWrite "false" ];
:reference [
a :Reference;
:referenceCount "2";
:referenceList (
<info:hdl/1234/567#index=4>
<info:hdl/567/1234#index=7> ) ];
:timestamp "2007-02-28T17:08:15Z";
:ttl [
a :TTL;
:ttlType "relative";
:ttlValue "86400" ];
:type "URL" ] ) .
<info:hdl/1234/567#index=4> a :HandleValue .
<info:hdl/567/1234#index=7> a :HandleValue .
#ENDS
####
********************************************************************************
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