| RDF-AllegroGraph-Easy documentation | Contained in the RDF-AllegroGraph-Easy distribution. |
RDF::AllegroGraph::Catalog - AllegroGraph catalog handle (abstract)
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);
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).
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.
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.
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);
@repos = $cat->repositories
This method returns a list of RDF::AllegroGraph::Repository objects of this catalog.
$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.
This method simply returns the version supported by the protocol, in the form of 3.3, or similar.
This method returns the protocol version the catalog supports.
Robert Barta, <rho at devc.at>
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-Easy documentation | Contained in the RDF-AllegroGraph-Easy distribution. |
package RDF::AllegroGraph::Catalog; use strict; use warnings; require Exporter; use base qw(Exporter);
sub repositories { die; }
sub repository { die; }
sub version { die; }
sub protocol { die; }
our $VERSION = '0.06'; 1; __END__