[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