[Dspace-tech] handle server

[Angelo Miranda]

Anyone has a script to start handle-server in background using a passphrase ?

Thank you
Angelo Miranda

-----Mensagem original-----
De: Tansley, Robert [mailto:***@hp.com]
Enviada: segunda-feira, 19 de Maio de 2003 21:30
Para: Mark O'Neil; dspace-***@lists.sourceforge.net
Assunto: RE: [Dspace-tech] handle server


Hi,

All the 'start-handle-server' script does is set up the relevant CLASSPATH and system properties, so that the CNRI Handle server and DSpace plug-in have the right environment. It's use is of course optional. If you need to use a passphrase, you can remove the 'nohup' and the '</dev/null' from the last line in start-handle-server (or enter the commands manually.)

The problem with having a passphrase on your Handle server is that it makes it rather awkward to stop and start the service. You couldn't have it automatically start up on a reboot, for example. (Unless you employed some nasty STDIN/STDOUT piping hack!)

Robert Tansley / Hewlett-Packard Laboratories / ([phone]

-----Original Message-----
Sent: 19 May 2003 15:13
Subject: [Dspace-tech] handle server
What exactly does the dspace provided start-handle-server do? It
appears to start the handle server and bind it to log output
- anything
else dspace specific?
The script as is does not run if you are using a passphrase on your
keys - or am i missing something simple here.
thanks,
-m
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software.

http://www.objectstore.net/sourceforge
_______________________________________________
DSpace-tech mailing list
DSpace-***@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge

[Ron Peterson]

This is from http://hs9.cnri.reston.va.us/CNRIHS/index.html

NOTE: If you are planning to implement DSpace(digital repository
project - MIT Libraries) then a subnaming authority from the CNRI
Public Handle Service is NOT what you want. You will need to set up
your own local handle service. To begin this please go to the
handle.net software download page for the latest handle server
distribution. Thank you.

So yet another service to maintain.

Which leads to some questions: why does dspace use the handle service at
all? What's wrong with using URL's? What advantage does the handle
service provide?

[Jason Simms]

I in some ways wonder why DSpace uses handles as well. DSpace links
that use handles simply link to the main item page, and not to any one
actual file (e.g., not directly to a Word document). I don't know why
handles are needed, because whether the bitstream is a Word document
or a PDF, or whether the "item" is actually fifty bitsptreams, the
handle will still only link to an item web page. I always wanted some
more clarification on that topic myself...

Jason Simms

Post by Ron Peterson
This is from http://hs9.cnri.reston.va.us/CNRIHS/index.html

NOTE: If you are planning to implement DSpace(digital repository
project - MIT Libraries) then a subnaming authority from the CNRI
Public Handle Service is NOT what you want. You will need to set up
your own local handle service. To begin this please go to the
handle.net software download page for the latest handle server
distribution. Thank you.

So yet another service to maintain.
Which leads to some questions: why does dspace use the handle service at
all? What's wrong with using URL's? What advantage does the handle
service provide?

[Tom De Mulder]

Post by Ron Peterson

[Handle server]

So yet another service to maintain.
Which leads to some questions: why does dspace use the handle service at
all? What's wrong with using URL's? What advantage does the handle
service provide?

The idea is to have long-lasting item identifiers, in case http gets
replaced by something else. I can see the point of this in the context of
a really long-term archive, although I think it'll become a moot point
with the progression of search engines, both inside DSpace and on the web
in general.

Also, I'm not convinced that CNRI as an institution will outlive the http
protocol - I'd much rather have the handles assigned by a real public
internet authority like IANA. And I think that, should http go the way of
gopher, people will provide gateways for the old protocol still to work.

Personally, I'm not convinced of the worth of the handle server, and it
certainly is another painful step in the installation and maintenance of
DSpace.

--
Tom De Mulder <***@cam.ac.uk> - Cambridge University Computing Service
DSpace @ Cambridge
->12/11/2003 : The Moon is Waning Gibbous (80% of Full)

[Tansley, Robert]

There are two issues highlighted in this thread.

1) Why Handles and not just URLs?

2) Why do Handles get resolved to Item pages and not directly to PDFs etc?

Both are explained in the documentation: http://dspace.org/technology/system-docs/functional.html#handles

To summarise:

1) Why Handles and not just URLs?

Handle names do not contain any semantic or location information. You can move the content identified by Handles around servers and organisations without changing the Handle. There are other ways of achieving this, but the Handle system has a well-developed, scalable infrastructure. Additionally, CNRI host the IETF, so they're hardly a small start-up company, and the DOI system is based on Handle infrastructure. These facts make us fairly confident that the Handle system and infrastructure won't suddenly 'disappear'.

2) Why do Handles get resolved to Item pages and not directly to PDFs etc?

To quote the docs:

"Bundles and bitstreams are not assigned Handles, since over time, the way in which an item is encoded as bits may change, in order to allow access with future technologies and devices. Older versions may be moved to off-line storage as a new standard becomes de facto. Since it's usually the item that is being preserved, rather than the particular bit encoding, it only makes sense to persistently identify and allow access to the item, and allow users to access the appropriate bit encoding from there."

We could, in the case of items that have just one bitstream (say a PDF), have the Handle direct the user straight to the PDF. However, PDF is rather a 'dead end', in that the user can't then easily navigate to the metadata (which may have information about newer revisions of the document) or the rest of the DSpace site. That's why we had the Handles resolve to the item metadata pages.

You can change that if you really want by changing the org.dspace.handle.HandleManager.resolveToURL() method.

Robert Tansley / Hewlett-Packard Laboratories / ([phone]

-----Original Message-----
Tom De Mulder
Sent: 12 November 2003 18:14
Subject: Re: [Dspace-tech] handle server

Post by Ron Peterson

[Handle server]

So yet another service to maintain.
Which leads to some questions: why does dspace use the

handle service

Post by Ron Peterson
at all? What's wrong with using URL's? What advantage does

the handle

Post by Ron Peterson
service provide?

The idea is to have long-lasting item identifiers, in case
http gets replaced by something else. I can see the point of
this in the context of a really long-term archive, although I
think it'll become a moot point with the progression of
search engines, both inside DSpace and on the web in general.
Also, I'm not convinced that CNRI as an institution will
outlive the http protocol - I'd much rather have the handles
assigned by a real public internet authority like IANA. And I
think that, should http go the way of gopher, people will
provide gateways for the old protocol still to work.
Personally, I'm not convinced of the worth of the handle
server, and it certainly is another painful step in the
installation and maintenance of DSpace.
--
Computing Service
->12/11/2003 : The Moon is Waning Gibbous (80% of Full)
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,
and more! http://www.apachecon.com/
_______________________________________________
DSpace-tech mailing list
https://lists.sourceforge.net/lists/listinfo/d> space-tech

[Ron Peterson]

Post by Tansley, Robert
1) Why Handles and not just URLs?
Handle names do not contain any semantic or location information. You
can move the content identified by Handles around servers and
organisations without changing the Handle. There are other ways of
achieving this, but the Handle system has a well-developed, scalable
infrastructure. Additionally, CNRI host the IETF, so they're hardly a
small start-up company, and the DOI system is based on Handle
infrastructure. These facts make us fairly confident that the Handle
system and infrastructure won't suddenly 'disappear'.

Neither do URL's contain semantic or location information, unless you
put it there. All of the qualities you mention apply to URL's. So
again, what distinguished handles from URL's? (I'm not going to make
niggling distinctions between URL's, URI's, and URN's here..) In fact,
until we see widespread adoption of CNRI's handle resolver plug-in,
people will be referring to handles by embedding them in URL's.

So far, dspace only provides bitstream preservation; but has ambitions
to provide functional preservation. Is this where handles come in?

[Hussein Suleman]

hi

and while we're on this topic, here's a non-US/Europe question...

what happens when the network connection between CNRI and your users is
broken? a typical case is when the international link between south
africa and the rest of the world goes down (at least an hour a week at
my institution). does the handle system have a network of caching
servers with hierarchical name divisions like DNS? i tried reading the
docs again but it doesnt seem like it does. am i missing something or do
all name resolutions go through the central site?

and for the record, i think handles and purls and all that stuff is
really neat ... but, realistically, neat doesn't "cut the mustard" when
u're sitting at a computer in south africa and every redirection is
another possibility of failure, where the worst failure is probably not
being able to access your own local resources because a global service
is not contactable!

ttfn,
----hussein

Post by Ron Peterson

Post by Tansley, Robert
1) Why Handles and not just URLs?
Handle names do not contain any semantic or location information. You
can move the content identified by Handles around servers and
organisations without changing the Handle. There are other ways of
achieving this, but the Handle system has a well-developed, scalable
infrastructure. Additionally, CNRI host the IETF, so they're hardly a
small start-up company, and the DOI system is based on Handle
infrastructure. These facts make us fairly confident that the Handle
system and infrastructure won't suddenly 'disappear'.

Neither do URL's contain semantic or location information, unless you
put it there. All of the qualities you mention apply to URL's. So
again, what distinguished handles from URL's? (I'm not going to make
niggling distinctions between URL's, URI's, and URN's here..) In fact,
until we see widespread adoption of CNRI's handle resolver plug-in,
people will be referring to handles by embedding them in URL's.
So far, dspace only provides bitstream preservation; but has ambitions
to provide functional preservation. Is this where handles come in?

[Richard Jones]

Although internally DSpace refers to URLs like
http://mydspace.edu/handle/11234/678 this is not actually the handle. The
handle is http://hdl.handle.net/11234/678 which points to the first URL. So
if the global service is down DSpace will still function perfectly well
internally (it just means that reference via handle may not work).

The problem with the connection being down or the service being down is just
one of a number of problems that persistent identification poses. My
personal favourite is the almost Godelian nature of the fact that in order
to have persistent identifiers it is necessary to have an identifier which
is persistent without it being a "persistent identifier" ;) This problem is
not solved and I think that it will be a little while before a truly
persistent solution is hit upon.

Richard
==============================
Richard Jones
Systems Developer
Theses Alive! - www.thesesalive.ac.uk
Edinburgh University Library
***@ed.ac.uk
0131 651 1611


----- Original Message -----
From: "Hussein Suleman" <***@cs.uct.ac.za>
To: <dspace-***@lists.sourceforge.net>
Sent: Monday, November 17, 2003 4:49 PM
Subject: Re: [Dspace-tech] handle server

Post by Hussein Suleman
hi
and while we're on this topic, here's a non-US/Europe question...
what happens when the network connection between CNRI and your users is
broken? a typical case is when the international link between south
africa and the rest of the world goes down (at least an hour a week at
my institution). does the handle system have a network of caching
servers with hierarchical name divisions like DNS? i tried reading the
docs again but it doesnt seem like it does. am i missing something or do
all name resolutions go through the central site?
and for the record, i think handles and purls and all that stuff is
really neat ... but, realistically, neat doesn't "cut the mustard" when
u're sitting at a computer in south africa and every redirection is
another possibility of failure, where the worst failure is probably not
being able to access your own local resources because a global service
is not contactable!
ttfn,
----hussein

Post by Ron Peterson

Post by Tansley, Robert
1) Why Handles and not just URLs?
Handle names do not contain any semantic or location information. You
can move the content identified by Handles around servers and
organisations without changing the Handle. There are other ways of
achieving this, but the Handle system has a well-developed, scalable
infrastructure. Additionally, CNRI host the IETF, so they're hardly a
small start-up company, and the DOI system is based on Handle
infrastructure. These facts make us fairly confident that the Handle
system and infrastructure won't suddenly 'disappear'.

Neither do URL's contain semantic or location information, unless you
put it there. All of the qualities you mention apply to URL's. So
again, what distinguished handles from URL's? (I'm not going to make
niggling distinctions between URL's, URI's, and URN's here..) In fact,
until we see widespread adoption of CNRI's handle resolver plug-in,
people will be referring to handles by embedding them in URL's.
So far, dspace only provides bitstream preservation; but has ambitions
to provide functional preservation. Is this where handles come in?

[Jane Euler]

If the handle system scales so well, why has the CNRI suddenly become
reticent to host handles for people's dspace installations?

This question shows a misunderstanding that I must point out. CNRI was
never going to host DSpace servers(we were never asked). The handle server
was part of the DSpace distribution from the beginning. There was no sudden
decision made in this regard.
The reason we put the sentence on the Public Handle site(that was referred
to in an earlier post) was to try to prevent people from requesting a
subnaming authority for the Public site when in fact that is not what is
required for a DSpace installation. The Public Handle server is for those
wishing to create a few(hundred or so) handles to test drive the system
without going through an installation.

Jane Euler
CNRI

Post by Tansley, Robert
1) Why Handles and not just URLs?
Handle names do not contain any semantic or location information. You
can move the content identified by Handles around servers and
organisations without changing the Handle. There are other ways of
achieving this, but the Handle system has a well-developed, scalable
infrastructure. Additionally, CNRI host the IETF, so they're hardly a
small start-up company, and the DOI system is based on Handle
infrastructure. These facts make us fairly confident that the Handle
system and infrastructure won't suddenly 'disappear'.

Neither do URL's contain semantic or location information, unless you
put it there. All of the qualities you mention apply to URL's. So
again, what distinguished handles from URL's? (I'm not going to make
niggling distinctions between URL's, URI's, and URN's here..) In fact,
until we see widespread adoption of CNRI's handle resolver plug-in,
people will be referring to handles by embedding them in URL's.
So far, dspace only provides bitstream preservation; but has ambitions
to provide functional preservation. Is this where handles come in?