[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] HS_VLIST for chaining handles?
Hi:
(Never averse to replying to my own questions.)
I just realized after posting this that the HS_VLIST type allows for mixing
in discrete handle values rather than the complete set of values at a given
handle. This is a very useful admin functionality but perhaps more fine
grained than what I was reaching for.
If one wanted to import (or let's just say 'reference" to avoid contention)
all handle values maybe the simplest way would just be to use a type of
'HDL' (or similar). I don't think there is a registered type but then I'm
not sure how to get a listing of all registered types. (Is there a way to
get such a complete listing?)
So, using the terminology of the previous example would something like this
{
"index" : "123" ,
"type" : "HDL" ,
"data" : "test/2"
"permission" : "1110" ,
"ttl" : "+86400" ,
"timestamp" : "Sun Nov 25 13:33:30 GMT 2007" ,
"reference" : []
}
be a reasonable approach to importing (or at least, referencing) values from
"hdl:test/2"?
(And apologies for the extraneous "}," in the earlier example.)
Course that also leads to questions about parent/child or master/slave
relationships between two paired handles. I guess, that kind of relationship
could be built in to the typing but may be best to leave it as a simple peer
level relationship with bidirectional references:
hdl:test/1 -> hdl:test/2
hdl:test/2 -> hdl:test/1
Cheers,
Tony
On 29/4/08 17:14, "Hammond, Tony" <t.hammond@nature.com> wrote:
> Hi:
>
> Is there any recommended way to chain handles together, i.e. to keep two
> handles in lockstep? Would this be an appropriate use of the HS_VLIST
> predefined type?
>
> Let's say, for sake of argument, that hdl:test/2 was being used to extend
> hdl:test/1 value space. Would the simple inclusion of a value (say index 42
> of hdl:test/2) in hdl:test/1 as e.g. (here using JSON "compact" syntax which
> uses the handle URI querystring form to denote a handle value)
>
> {
> "index" : "123" ,
> "type" : "HS_VLIST" ,
> "data" : [ hdl:test/2?index=42 ]
> } ,
> "permission" : "1110" ,
> "ttl" : "+86400" ,
> "timestamp" : "Sun Nov 25 13:33:30 GMT 2007" ,
> "reference" : []
> }
>
> be sufficient to "lock in" hdl:test/2 and so all values from hdl:test/2.
>
> Could this be seen as something like an "include" statement wrt values? I
> know that the handle specs make no semantic claims (apart from noting that "
> HS_VLIST values may be used to define administrator groups for handles") and
> that these are merely a collection of pointers. But could that be a
> reasonable interpretation? Sort of like an rdfs:seeAlso property?
>
> (Note: In JSON "full" syntax the data element would be expressed more
> uncompactly as something like:
>
> "data" : {
> "referenceCount" : "1" ,
> "referenceList" : [
> { "handle" : "test/2" , "handleValueIndex" : "42" }
> ]
> } ,
> )
>
> 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
_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info