Martin 'Kingpin' Thurn > RDF-AllegroGraph-Easy-0.09 > RDF::AllegroGraph::Catalog

Download:
RDF-AllegroGraph-Easy-0.09.tar.gz

Dependencies

Annotate this POD

CPAN RT

New  1
Open  2
View/Report Bugs
Module Version: 0.06   Source  

NAME ^

RDF::AllegroGraph::Catalog - AllegroGraph catalog handle (abstract)

SYNOPSIS ^

   my $server = new RDF::AllegroGraph::Server (ADDRESS => 'http://localhost:8080');
   my $vienna = new RDF::AllegroGraph::Catalog (NAME => '/vienna', SERVER => $server);

   warn "all repositories in vienna: ".Dumper $vienna->repositories;

   # open an existing
   my $air   = $vienna->repository ('/vienna/air-quality');
   # create one if it does not exist
   use Fcntl;
   my $water = $vienna->repository ('/vienna/water', mode => O_CREAT);

DESCRIPTION ^

AllegroGraph catalogs are containers for individual repositories (RDF::AllegrGraph::Repository). The latter roughly correspond to what the RDF folks call a model. You can get a catalog handle from the AG server (RDF::AllegroGraph::Server).

Naming

AllegroGraph understands catalogs and repositories. While the latter are mostly what RDF model are called elsewhere, catalogs are containers for a set of repositories. Named catalogs are supported by this interface, you will have to configure them either in the agraph.cfg configuration file, or create them with the web interface (since AGv4). Since AGv4 there is also the root container. It always exists.

To provide a consistent naming, this interface uses a simple path language:

/

This specifies the root container. Any repository (such as, say, catlitter) is addressable via /catlitter.

/[named]

Named catalogs (such as, say, scratch) are addressed as /scratch and, yes, without further context it is now not decidable whether /scratch is a repository inside the root catalog or a catalog on it own.

Anyways, .... repositories inside one named catalog are again unambigously addressable, such as /scratch/catlitter.

AG version 3 and 4

This is interface supports AGv3 (3.3 onwards) and AGv4 (4.2 onwards), even though many features will be missing (until I really need them). Still, the overall interface tries to be as version agnostic as possible. When this fails, you should consult the proper subclass for the version, such as RDF::AllegroGraph::Server4 for example.

INTERFACE ^

Constructor

The constructor expects the following options:

NAME (mandatory, string)

This is a string of the form /mycatalog and it identifies that very catalog on the server.

SERVER (mandatory, RDF::AllegroGraph::Server object)

This is the handle to the server.

Example:

   my $server = new RDF::AllegroGraph::Server (...);
   my $vienna = new RDF::AllegroGraph::Catalog (NAME => '/vienna', SERVER => $server);

Methods

repositories

@repos = $cat->repositories

This method returns a list of RDF::AllegroGraph::Repository objects of this catalog.

repository

$repo = $cat->repository ($repo_id [, $mode ])

This method returns an RDF::AllegroGraph::Repository object for the repository with the provided id. That id always has the form /somerepository.

If that repository does not exist in the catalog, then an exception cannot open will be raised. That is, unless the optional mode is provided having the POSIX value O_CREAT. Then the repository will be created.

version

This method simply returns the version supported by the protocol, in the form of 3.3, or similar.

protocol

This method returns the protocol version the catalog supports.

AUTHOR ^

Robert Barta, <rho at devc.at>

COPYRIGHT & LICENSE ^

Copyright 20(09|1[01]) Robert Barta, all rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

RDF::AllegroGraph

syntax highlighting: