Information Technology Reference
In-Depth Information
To solve these problems, we have selected
UUID as the unique ID in the CDOI cloud. In
CDOI, we adopt two UUIDs to replace the DOI
name. The first UUID is the organization/person
identifier name; the second UUID is the internal
identifier name. The overall length of a CDOI name
is 64 bytes. The advantages of using UUID are:
UUID can be generated automatically by many
programs while guaranteeing the uniqueness; the
length of the CDOI name is fixed, which is good
for storage and index; it is easy to be automatically
processed, which can be used to name the massive
user-generated content from Web2.0 applications;
and it is easy to be distributed on many servers,
which provides CDOI with high scalability.
The services that this cloud provided are
register, delete, update an ID, and resolve ID to
the real location of the resource or the metadata
of the resource. Besides the direct services, we
also provide the service of agency management.
file, BerkelyDB can support up to 4TB. As for the
query on multiple documents, BerkelyDB provides
functions to open them all for complex query.
The schema of a digital resource can be gener-
ated from the tool automatically. Once complete,
the database can verify the data formats according
to this schema file. To speed up the query, the
indexes are built. We plan to support dynamic
index creation according to the statistical analysis
of the query history at the next stage.
Because CDOI and WMMS both include the
Dublin Core information, there exist the possibility
for data inconsistencies to occur. We solve this
problem by providing a special mark in WMMS
called “cdoiReference” that points to the ID entry
in CDOI.
For the query result, we provide two formats
to return to the user: one is XML, and the other
is JSON which uses two-dimensional array to
package the whole result. This was chosen be-
cause JSON decreases the size of the result, thus
increases the efficiency of transportation.
5.2. WMMS
5.3. WFMS
WMMS is used to manage the metadata of the
digital resources. The properties of it can be
classified into two parts: the basic part and the
extension part. The basic part includes the basic
metadata of the digital resource, for which we
use Dublin Core set to present it. However, for a
digital resource, there are many different properties
belonging to the extension part and it is difficult
to maintain these properties in a fixed column
relational database. As for a digital resource, its
properties may change as it evolves. In regards
to data storage, we chose BerkleyDB which is a
high performance open source XML database. It
is implemented in C/C++, we use JNI to call it
and XPath/XQurey to query the database.
The services it provides are creating a new
XML document (similar to a table in RDB), query-
ing on the documents, and deleting a document.
Each document is included in a single file. For
a new type of digital resource, we use a file to
store the data. In regards to the size of the single
Generally, every website provides its own upload-
ing and downloading modules so that users can
share resources. However, the resources uploaded
to websites' servers are often lack of unified and
professional management. What's more, when
the amount of users using the uploading and
downloading modules increases, it will bring a
high pressure on the website's server in terms of
bandwidth. WFMS is used to solve these problems.
It provides a unified interface for multiple web-
sites to upload, download and manage resources
professionally, and decreases the developing costs
and bandwidth pressure as well.
As a service container, WFMS provides two
kinds of services. One is to use WFMS as a SaaS
service. Users can apply for Web storage and use
it on the Internet directly. The other is to utilize it
in the applications which can be used in two ways.
One is to use it as a Web Service provider, from
Search WWH ::
Custom Search