[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Handle-info] OpenHandle: Bitmask or Boolean?
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