Octapy3 was developed to create “cooperating communities” of knowledge providers in a distributed environment. Octapy3 is entirely written in Python, it uses the Zope Application Server and the Plone CMS as web publishing tool. The design architecture is a component-based architecture using the Zope3 CA framework. There are components to integrate the OAI protocol in order exchange metadata among applications, to explicitly create relations among documents allocated in different computational node. Also the Octpay3 framework manages cartographic document and RDF/RDFS serialization of documents and content types. In the rest of the paper we describe the component architecture adopted, wit special attention to the functionalities and techniques used to overcome the Zope/Plone environment. Next, the Octpay Configuration Markup Language (OCML) is described together some example of its usage to described the document structure, the component description. OCML allows to personalize the managed contents, to easily extend the environment and to establish relations among documents. The paper describes also the set up used to test it with cultural heritage contents. We developed the napolibniculturali.it network of cultural heritage knowledge providers. To each provider the Octapy3 environment provide them with a set of tools, for example, to implement the cartographic interface for contents mediation, to build intermuseum virtual collections, stressing out either the effective visit or the conceptual features. napolibeniculturali.it is sponsored and used by the Direzione Regionale per i Beni Culturali e Paesaggistici della Campania to promote knowledge about cultural heritage goods of Campania. Currently this community is built of about 50 information node providers, and it interoperates with the Italian cultural heritage portal managed by the Italian Ministers of Cultural Heritage
Call Girls In Panjim North Goa 9971646499 Genuine Service
Carmine Noviello Octapy3 A Distributed And Cooperative Semantic Web Oriented Cms
1. Octapy 3: a distributed and
cooperative semantic
web oriented CMS
Mario Mango Furnari, Carmine Ivan Delio Novello, Paolo Acampa
Istituto di Cibernetica “E. Caianiello”
National Research Council
Pozzuoli
Italy
Octapy 3 was developed to create “cooperating communities” of knowledge providers in a distributed
environment. Octapy 3 is entirely written in Python, it uses the Zope Application Server and the Plone
CMS as web publishing tool. The design architecture is a component-based architecture one starting
from the Zope3 CA framework. There are components to integrate the OAI protocol in order exchange
metadata among applications, to create explicit relations among documents allocated in different
computational node. The Octpay3 framework manages cartographic document too.
In the paper we describe the component architecture adopted, wit special attention to the functionalities
and techniques used to overcome the Zope/Plone environment. Next, the Octapy Configuration Mark-
up Language (OCML) is described together some example of its usage to described the document
structure. OCML allow both to personalize the managed contents and to easily extend the environment.
The set up used to test it with cultural heritage contents is also described.
We developed the napolibniculturali.it network of cultural heritage knowledge providers. To each
provider the Octapy3 environment provide them with a set of tools, for example, to implement the
cartographic interface for contents mediation, to build intermuseum virtual collections, stressing out
either the effective visit or the conceptual features. napolibeniculturali.it is sponsored and used
by the Direzione Regionale per i Beni Culturali e Paesaggistici della Campania to promote
knowledge about cultural heritage goods of Campania. Currently this community is built of
about 50 information node providers, and it interoperates with the Italian cultural heritage
portal managed by the Italian Ministers of Cultural Heritage.
Istituto di Cibernetica “E. Caianiello”
via Campi Flegrei, 34
Pozzuoli - Napoli
info@ais.cib.na.cnr.it
2. Cooperative communities and Content Management Systems
Thanks to diffusion of low cost high-speed Internet connections, institutions and organizations
face increasing demands to cooperate in sharing common knowledge. Many public institution,
museum and library publish their contents over network in a digital manner. Much of this
content is dynamically produced using of server side and distributed services technology.
Today content delivery and sharing information across the network is possible using a
variety of technologies, such as distributed databases, service oriented applications, and so
forth. Nevertheless, sharing content technology is only one aspect of content management in
cooperative and distributed settlement. Furthermore, content needs to be created, managed,
revised and finally published. It needs also to be aggregated in digital collection which in turn
are eventually shared. Content Management Systems (CMS) are suitable for this part of content
management. Modern CMS, like Plone, exposes very complete environment to support users
in content production. Thanks to a powerful, complete and user-friendly interface it is very
simple to create, to manage and to store content. However most of CMS has a poor support to
document distribution over the network which it suitable for the system interoperability. They
mainly focus the attention essentially on the users’ interaction and documents use. Documents
do not play an active rule in content sharing.
To share documents in a machine understandable way de facto representation standard for
contents, like XML and RDF technologies, and metadata, like Dublin Core and OAI, are necessary.
Moreover, documents must provide both user and machine oriented different representations,
and play an active rule in sharing of data.
Octapy is a distributed environment for content management that meets these challenges.
It does this by combining a number of key features including:
Powerful component model: Octapy introduces a flexible component model that
enables the creation of content-oriented extension that can be generic and not tightly
coupled with the documents schema. To share contents represented though different
documents schema an abstract model to add context dependent information to metadata
is defined.
Multiple document representations: each document in Octapy provides multiple
representations user and machine oriented. Using the XML and RDF widespread standard,
documents can be exchanged across different web site even if they haven’t the proper
document definition.
Support to semantic web technologies: Octapy brings semantic web technology in
a powerful Content Management System, allowing interoperability to other systems.
It introduces a document model suitable for interoperability with legacy system and
provides a framework for development of custom document interpreters.
Extensible metadata management: Octapy documents contain metadata that can
express any type of relationships such as membership in collections, parent-child
relations or taxonomic relationships. Moreover, Octapy document repositories are fully
conformant with the Open Archive Initiative Protocol for Metadata Harvesting (OAI-
PMH).
Introduction to Octapy 3
Octapy adds new functionalities to the Plone CMS, such as support distributed documents
over the network, fast definition of new content types using a configuration language and a
2
3. component model to easily build new extensions. In Octapy, contents play a central role and
they are active part of the process of interoperability between different systems. Contents aren’t
only data, but active software components that exposes a well-defined API and different kind of
representations both user and machine oriented.
From an architecture point of view, Octapy can be split into three main application levels.
Figure 1 schematizes such levels.
Figure 1 - Octapy 3 Architecture
Documents Definition Layer: Octapy adds functionalities to simplify defining process
for new document types. In Octapy the document definition is carried out during the
configuration phase, introducing a new XML-based format called OCML, in contrast to Plone
where the definition of new content types is achieved using the Archetype framework,
that imply the development of a new product must by carried by the user. Furthermore,
such product must provides all archetypes with their application and presentation logic.
Content Components Layer: one of the main goals of Octapy is to abstract from the content
structure introducing a clear separation among application layers, achieved using the Zope
3 Component Architecture. Starting from configuration file expressed in OCML, Octapy
generates specific components that represent contents, called “content component”, that
expose an interface that describes the structure of document, the relations with other
documents and other kind of information useful for developing additional functionalities.
Distributed and Cooperative Layer: Octapy is designed to build communities of cooperating
web information node providers. Therefore, special attention has been paid to support
standards for interoperability, such as XML for data representation, RDF/RDFS for semantic
interoperability, DC (Dublin Core) metadata set and OAI (Open Archive Initiative) protocol
for metadata exchange among heterogeneous systems. Thanks to these standards and
protocols, web sites build using Plone CMS and the Octapy extension can easily exchange
documents, allow distributed search and other kind of interoperability, even if a web
site hasn’t the proper document definition. In Plone only known type of content types
could be handled while in Octapy remote documents even if a local web site hasn’t the
corresponding content type definition could be managed.
The Octapy Configuration Mark-up Language
One of the Octapy goals is to allow new content types definition during the CMS installation
and setup configuration phase, without requiring to write Python code. To pursue this goal we
defined a new configuration language, called Octapy Configuration Mark-up Language (OCML)
an XML-based configuration language that allows: to define new document types, to choose the
storage methods for documents or part of them and to assign user presentation to contents.
3
4. The OCML tags, called directives, are grouped in three main categories, labelled using
the XML namespaces: data, storage and view. A minimal OCML document structure is:
<octapy xmlns:view=”http://namespaces.remuna.org/octapy-view”
xmlns:data=”http://namespaces.remuna.org/octapy-data”
xmlns:storage=”http://namespaces.remuna.org/octapy-storage”>
…
</octapy>
The OCML:
namespace data. The data directives allow the user to define: new content types
and the associated structure (that is the fields of the content), to express parent-child
relationship among documents. For example, in Octapy, documents can be composed
to form hierarchical structures using the containment relation “is-composed-by” and
the corresponding “is-part-of”. A document that can contain other documents is called
containerish document, and it acts simultaneously in Plone like a simple content and
a folder.
A new content type is defined by the data:document directive, and fields are
defined using data:field directives. Fields can be logically grouped using data:
section directives (they will appear in different archetype schemata).
<octapy xmlns:view=”http://namespaces.remuna.org/octapy-view”
xmlns:data=”http://namespaces.remuna.org/octapy-data”
xmlns:storage=”http://namespaces.remuna.org/octapy-storage”>
<data:document name=”Artistic Object” id=”ArtisticObject”
subtypes=”(localization, status)”>
<data:section name=”General Info”>
<data:field name=”id” type=”String” languageIndependent=”True”
default=”1000” mode=”r” />
<data:field name=”title” type=”String” searchable=”True”
languageIndependent=”false” required=”True”
default=”Title”/>
<data:field name=”oss” type=”Text” searchable=”true”
languageIndependent=”false” required=”false”
metadata=”{‘uiuse’:’description’}” />
<data:field name=”inventory” type=”int” searchable=”true”
languageIndependent=”true” required=”false” />
<data:field name=”image” type=”Image” searchable=”false”
languageIndependent=”true” required=”true” />
</data:section>
</data:document>
</octapy>
The previous OCML code fragment defines a new content type named “Artistic Object”
(a kind of cultural heritage used to catalogue artistic object like paints, furniture, etc)
that can have two subdocuments (localization and status). ArtisticObject
has five fields defined by the data:field directive. Each field has its type, defined
by the name attribute, plus other options that are mainly Archetype schema field
attribute (as described forward in the document, Octapy generates corresponding
4
5. Archetype schema starting from OCML directives). The special attribute metadata will
be further described in next section.
namespace storage. Using the namespace storage directives the user can associate
to a document or a part of it, of a given content type, a storage mechanism. The
following fragment of OCML code defines that ArtisticObject has persistence into a
PostgreSQL database (using the archetype ability to serialize objects into database via
Zope Adapters), but the field image has the specific persistence into the filesystem (at
path specified with the corresponding param).
<octapy xmlns:view=”http://namespaces.remuna.org/octapy-view”
xmlns:data=”http://namespaces.remuna.org/octapy-data”
xmlns:storage=”http://namespaces.remuna.org/octapy-storage”>
<storage:apply
for=”ArtisticObject”
type=”Postgres”>
<param name=”dbname”>preale</param>
<param name=”user”>username</param>
</storage:apply>
<storage:apply
for=”ArtisticObject.image”
type=”FS”>
<param name=”path”>/usr/local/data/images</param>
</storage:apply>
</octapy>
namespace view: Using the namespace view directives the user can define specific
aspects related to the document presentation. It’s possible to define which widget to
use to display a field of a document. Two directives can be used to cover this operation:
view:for, used to specify the widget of a specific field; view:fordata used to
specify the widget of a field type (e.g. Text, Image, ecc). The following fragment of
OCML code shows the view:fordata directive usage.
<octapy xmlns:view=”http://namespaces.remuna.org/octapy-view”
xmlns:data=”http://namespaces.remuna.org/octapy-data”
xmlns:storage=”http://namespaces.remuna.org/octapy-storage”>
<view:widget
fordata=“Text”
type=“StringWidget”
<view:configure>
<view:param name=”maxlength”>255</view:param>
</view:configure>
</view:widget>
</octapy>
The OCML specification allows arranging directives between multiple files using the
special directive <include src=”filename” />. For a more detailed OCML reference, see
5
6. [ACAM07].
The Octapy 3 component model
Thanks to Zope 3 Component Architecture, Octapy utilizes the component model also for
the document contents, so that it is possible to abstract from the specific content schema. To
achieve that we developed the Octapy “content components” that it is in charge to automatically
generate the Zope 3 components starting from OCML document type description. The generation
process is carried out from YODA (Yoda is Octapy Document Assembler) that generates both
the archetype code and the interface describing the document structure. This interface is an
enumeration of attributes for each field of the content type and the corresponding archetype
class implements this interface leading to a “content component”.
Figure 2 – The Octapy component model
Each content component implements, see Figure 2, at least two interfaces: the content
type definition and the IOctapyInterface. IOctapyInterface is an interface common to
all content components and exposes the method getContentInteface() which returns the
interface describing the content type, i.e. it allows to lookup for the specific data interface. The
following Python code snippet illustrates the role of the IOctapyContent interface.
6
7. from Products.Octapy.interfaces import IOctapyContent
contents = aFolder.objectItems()
for c in contents:
if c.directlyProvides(IOctapyContent): #Ok, it’s an Octapy content
iface = c.getContentInterface()
print “Content-component interface: ”, iface
for attr in iface: print “Field: ”, attr
Running this script on a folder, containing instances of “ArtisticObject” so as defined in
the previous paragraph, generates the following output:
Content-Component inteface: IArtisticObject
Field: id
Field: title
Field: oss
Field: inventory
Field: image
The component model introduced in Octapy allows to handle all the managing contents
extensions in a generic way. An adapter, to the fixed interface IOctapyContent, adds the
required functionalities to Octapy system. For example, the presentation interfaces can be
built using Browser Pages component that adapts IOctapyContent and access to the content
interface via getContentInterface() method. Moreover, it also possible to write extensions
for a given data schema simply adapting the content component generated interface.
Interpretation models: the metadata attribute
The component model introduced by Octapy has been designed to make software reusable
and abstract from a particular data schema. All the Octapy extensions must be designed setting
aside from the structure of documents and the way to assign special meaning to field is to use
interpretation models.
In an application data layer, in general, the content fields have no associated meaning, since
they are only container used to store fixed data. For example, in the ArtisticObject defined
previously, the fields oss and title are simply container for lines of text. Nevertheless, to these
fields we can associate special meaning in other context, for example, oss is the description
field of an Artistic Object and in the presentation layer could be displayed to user with a given
layout, maybe under the image of the object with special formatting and typesetting. This
means that a document, or a part of it, can have special interpretation that must be handled
in proper way by the software.
In OCML a special attribute of data:field directive has been introduced: metadata, whose
values can be used to specify which interpretation model is associate to a field. For example,
the value:
<data:field name=”oss “ type=”Text” metadata=”{‘uiuse’:’description’}” />
points out to the presentation layer that the field is the description of an Artistic Object, and
7
8. must be properly processed. The values of metadata attribute are transparent to the data
layer and other application layers: only components that know how treat this information will
use it. The interpretation model is available to extension via the component model, using the
ability of Zope 3 interfaces to annotate attribute and method with tags. The corresponding
content interfaces generated by YODA is annotated with information provided in metadata
attribute using Zope 3 setTaggedValue() method. The following fragment of code shows the
corresponding interface generated from the OCML ArtisticObject content type definition.
from zope.interface import Interface
class IArtisticObject(Interface):
id = Attribute()
id.setTaggedValue(‘datatype’, ‘String’)
title = Attribute()
title.setTaggedValue(‘datatype’, ‘String’)
oss = Attribute()
oss.setTaggedValue(‘datatype’, ‘Text’)
oss.setTaggedValue(‘ui:use’, ’description’)
inventory = Attribute()
inventory.setTaggedValue(‘datatype’, ‘Int’)
IArtisticObject.setTaggedValue(’contenttype’, ’ArtisticObject’)
IArtisticObject.setTaggedValue(’contenttypename’, ‘Artistic Object’)
Extension modules can access to information provided via metadata attribute using the
corresponding getTaggedValue()method. The following snippet of code shows a possible
interpretation models application.
from Products.Octapy.interfaces import IOctapyContent
content = aFolder.objectItems()[0]
if content.directlyProvides(IOctapyContent):
iface = content.getContentInterface()
print “Inspecting contenttype: “, iface.getTaggedValue(“contenttype”)
for attr in iface:
if “uiuse” in iface[attr].getTaggedValues():
#Prints all attributes which have the metadata ‘uiuse’
uiuse = iface[attr].getTaggedVelue(“uiuse”)
value = iface[attr].value
print “Special attr ‘%s’ with uiuse ‘%s’: %s” % (attr, uiuse, value)
else:
value = iface[attr].value
type = iface[attr].getTaggedValue(‘datatype’)
print “Attr ‘%s’: %s(%s)” % (attr, value, type)
Running this script on a folder, that contains instances of “ArtisticObject” defined in the
previous paragraph, generates the following output:
8
9. Inspecting contenttype: ArtisticObject
Attr ‘id’: atoggettoartistico.2007-07-19.0117652569(String)
Attr ‘title’: Morte dell’ammiraglio Cotigly (String)
Special attr ‘oss’ with uiuse ‘description’: Il dipinto raffigura…
Attr ‘inventary’: 2111232(Int)
Attr ‘immge’: <byte data>(Image)
It is important to underline that interpretation models are not only used for presentation
logic, but may be used whenever it is necessary to associate a special meaning to a field. For
example, the Octapy Dublin Core subsystem uses the metadata attribute to map fields name to
the DC metadata set, as shown in the following example:
...
<data:field name=”descrizione_breve” type=”Text” metadata=”{‘dc’:’title’}”/>
<data:field name=”autore_scheda” type=”Text” metadata=”{‘dc’:’author’}”/>
...
Distributed and cooperative functionalities
Octapy has been designed to brings functionalities for content-based interoperability in
order to have communities of distributed contents providers that share common knowledge.
In Octapy the information sharing is achieved exchanging documents, each document has
multiple representations, most of them based on XML. One of the available representations is
called Octapy eXchange Format (OXF), an XML serialization exposed by all object that provide
the IOctapyContent interface. OXF exports both document content and its structure, that
is its content type definition. The following example shows the OXF serialization of an Artistic
Object.
<?xml version=”1.0” encoding=”UTF-8”?>
<octapy-document
xmlns:dc=”http://purl.org/dc/elements/1.1”
xmlns:cmf=”http://cmf.zope.org/namespaces/default”
xmlns:xmp=”http://octapycms.remuna.org/xmp”
xmlns:base=”http://octapycms.remuna.org/oxf” version=”3.0”>
<cmf:type name=”Artistic Object”>ArtisticObject</cmf:type>
<uid>1fa69193d3814971f2d9d0627191d771</uid>
<field
id=”id”
name=”id”
type=”id”>atoggettoartistico.2007-07-19.0117652569</field>
<dc:title>Morte dell’ammiraglio Cotigly</dc:title>
<dc:creator>v.izzo</dc:creator>
<dc:language>it</dc:language>
<translation lang=”en”>
http://preale.napolibeniculturali.it/docs/OA123-en
</translation>
<xmp:CreateDate>2007/07/19 15:00:11.824 GMT+2</xmp:CreateDate>
<xmp:ModifyDate>2007/07/19 15:00:12.113 GMT+2</xmp:ModifyDate>
<field
type=”String”
name=”title”
9
10. label=”Object title”>
<content>Morte dell’ammiraglio Cotigly</content>
</field>
<field
type=”Integer”
name=”inventory”
label=”Inventory number”>
<content>2111232</content>
</field>
<field
type=”Text”
name=”oss”
label=”Description”>
<content>Il dipinto raffigura.......</content>
<metadata name=”ui:use”>description</metadata>
</field>
</octapy-document>
An OXF serialization allows to implement and manage remote contents like local contents,
even in the case if the CMS doesn’t have the definition of the remote content type. OXF reports
the structure of document, its fields and their type, the content of each field and any additional
information necessary to manage a remote content. Octapy adds to default content types an
archetype called RemoteObject: it is used to store the URL of remote document, to parse the OXF
serialization, and to manage properly the document. Octapy manage RemoteObject as a content,
then it provides the IOctapyContent interface. A special base class of RemoteObject, called
OctapyProxy, manages the creation of the content interface, starting from the information
provided by OXF serialization. All interpretation models are properly added to fields providing
them so that presentation layer and other extension module can opportunely treat them.
The following python code snippet shows how it’s simple to manage remote content in Octapy
like a normal archetype stored into the CMS.
>>> from Products.Octapy.container import RemoteContainer
>>> from Products.Octapy.interfaces import IOctapyContainer, IOctapyProxy
#Obtains all documents stored in a remote container (folder)
>>> remoteFolder = RemoteContainer(“http://capodim.remuna.org/contents”)
>>> remoteFolder.directlyProvides(IOctapyContainer)
True
>>> contents = remoteFolder.objectItems()
>>> for c in contents:
... if c.directlyProvides(IOctapyContent): #Ok, it’s an Octapy content
print c.getContentInterface().getTaggedValue(“contenttype”)
...
OggettoArtistico
OggettoArtistico
......
>>> c.directlyProvides(IOctapyProxy)
True
#The content is in read only mode
>>> c.mode
’r’
>>> iface = c.getContentInterface()
#For the Italian National Museum of Capodimonte the description field is ‘oss’
>>> iface[‘oss’].getTaggedValue(‘uiuse’)
10
11. ’description’
>>> remoteFolder = RemoteContainer(“http://preale.remuna.org/contents”)
.......
>>> iface = c.getContentInterface()
#For the King Apartment in Naples the description field is
#‘descrizione_completa’
>>> iface[‘descrizione_completa’].getTaggedValue(‘uiuse’)
’description’
The example highlights also other Octapy interesting features. Folder as well documents can
be exported to other web sites and aggregated using the RemoteContainer class. Moreover,
every container in Octapy implements the IOctapyContainer interface and all remote contents
(documents and folders) implements the IOctapyProxy marker interface, i.e., those objects
are proxy for remote contents. Containerish documents expose both IOctapyContent and
IOctapyContainer interfaces.
Furthermore, the example shows the importance of the interpretation models too. Both
National Museum of Capodimonte and King Apartment in Naples preserve and manage Artistic
Objects although they don’t have an agreement to have the same field name for the heritage
good description field. They calls it oss (abbreviation of the Italian osservazione – in English
means observation) and descrizione_completa (in English means full description). Thanks
to interpretation models, system can treat it in the right way.
RDF/RDFS Serialization
To share data across web sites, Octapy makes available more representations. Some of
them are oriented to the semantic web and are based on RDF/RDFS language. The first step in
RDF serialization is the definition of a document model to be used in order to share a common
interpretation for the RDF classes and entities. Document model can be considered the RDF
equivalent of the Octapy component model: it acts as an abstract model to classify documents
and the associated interpretation. The following example shows a fragment the N3 serialization
of the Octapy document model.
@prefix : <http://octapycms.remuna.org/octapy#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
:BaseContent a rdfs:Class.
:OctapyContainer a rdfs:Class;
rdfs:subClassOf :BaseContent.
:OctapyContent a rdfs:Class;
rdfs:subClassOf :BaseContent.
:caption a rdfs:datatype;
rdfs:subClassOf xsd:string.
:description a rdfs:datatype;
rdfs:subClassOf xsd:string.
:title a rdfs:Property;
11
12. rdfs:domain :BaseContent;
rdfs:range xsd:string.
For each document in the CMS, two RDF serializations are available: one containing the RDF
schema representing the content type; the other containing the class instances with document
content. The following two examples show, respectively, the RDFS class of an Artistic Object
and its instance.
@prefix : <http://preale.napolibeniculturali.it/docs#>.
@prefix octapy: <http://octapycms.remuna.org/octapy#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
:inv a rdfs:Property;
rdfs:label “Invetory”^^<http://www.w3.org/2001/XMLSchema#string>;
rdfs:domain :ArtisticObject;
rdfs:range xsd:integer.
:loc a rdfs:Property;
rdfs:domain :ArtisticObject;
rdfs:range :localization.
:oss a rdfs:Property;
rdfs:label “Description”^^<http://www.w3.org/2001/XMLSchema#string>;
rdfs:domain :ArtisticObject;
rdfs:range octapy:description.
:localizzazione a rdfs:class;
rdfs:label “Localization”^^<http://www.w3.org/2001/XMLSchema#string>;
rdfs:subClassOf octapy:OctapyContent.
:ArtisticObject a rdfs:class;
rdfs:label “Artistic Object”^^<http://www.w3.org/2001/XMLSchema#string>;
rdfs:subClassOf octapy:OctapyContent.
@prefix : <http://preale.napolibeniculturali.it/docs#>.
@prefix contents: <http://preale.napolibeniculturali.it/contents#>.
@prefix dc1: <http://purl.org/dc/elements/1.1#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
contents:atoggettoartistico.2007-07-19.0117652569 a :ArtisticObject;
:loc [ a :localization];
:oss “Il dipinto raffigura.......”;
dc1:creator “v.izzo”;
dc1:language “it”;
dc1:title “Morte dell’ammiraglio Cotigly”.
It’s important to underline that the previous serializations are automatically generated by
12
13. Octapy, without any user intervention. RDF/RDFS serialization can be used in place of OXF
one.
RemoteObject uses Python rdflib library to parse RDF documents. Starting from RDF schema
it establishes the base class of the document. If it is an OctapyContent or OctapyContainer RDF
class, then it handles the document as Octapy document. Otherwise, it scans a global Zope list
called DIL (Document Interpreter List) finding any additional interpreters that can manage the
document. In this way, it is possible to extend Octapy to support other kind of RDF document,
in order to interoperate with other system, also with legacy systems too. For example, using
SquirrelRDF, a tool that can export database table in RDF graph, conventional DBMS legacy
data can be exported in a form suitable to be managed by Octapy, using the same document
model.
Octapy supports other form of interoperability through standard protocol for metadata
sharing, like the OAI-PMH protocol and the Dublin Core metadata set. Figure 4 shows the
interaction of the OAI Octapy subsystem with the component model. More information can be
found in [NOVI07].
Figure 4 – The integration of a OAI data provider in a Octapy based CMS
The napolibeniculturali.it test bed
We developed CMS Octapy having in mind his use in the context of Cultural Heritage
fostering. We started with the research project “Museo Virtuale di Napoli: Rete dei Musei di
Napoli” (ReMuNa)1 [REMU01]. Beside software and networking infrastructures design and
1
The project “Neapolitan Virtual Museum: the Neapolitan Network Museums” was budgeted by the Italian
Minister of University and Research (MIUR)
13
14. implementation 18 of the major museums in Naples were involved. Among them there were
Archivio di Stato di Napoli, Museo Archeologico Nazionale di Napoli, Museo di Capodimonte,
Certosa e Museo di San Martino, Museo Diego Aragona Pignatelli Cortes, Museo di Palazzo Reale,
Pinacoteca del Pio Monte della Misericordia, Museo del Tesoro di San Gennaro, Parco della Tomba
di Virgilio, Museo dell’opera di Santa Chiara. From the scientific point of view the main goals
were to verify on the field the possibility to create knowledge cooperating communities. Where
each participating could exchange its own managed knowledge so to improve their institutional
cooperation. Next, the Direzione Regionale per i Beni Culturali e Paesaggistici della Campania
decided to adopt both the organizational model, i.e. on one side to guarantee the autonomy of
the museum stakeholder and on the other side to improve the cooperation among the museums
and institutions, and the software platform. To foster the museums cooperation software tools
to aggregate the knowledge, both locally and remotely, were developed. Using these tools the
knowledge stakeholder could organize virtual exhibitions according to some physical or logical
criteria and regarding information, directly managed o shared with other stakeholders, about
cultural heritage goods. Currently the cultural heritage circuit of napolibeniculturali.it participate
more than 50 museums stakeholder. Since the software allow to exchange the contents through
the OAI-PMH then the circuit itself is included in the Italian cultural heritage portal2.
Figura 6 – The network infrastructure of napolibeniculturali.it
The network infrastructure on top of which the distributed CMS for the napolibeniculturali.it
community is running is built as a MPLS based Virtual Private Network (VPN). Each museum ha
an access point at 2 or 10 Mbps connected to its LAN. The VPN is connected to both Internet,
through a 4 Mbps channel, and to the network infrastructure of the Ministero per i Beni e le
Attività Culturali.
The Direzione Regionale per i Beni Culturali e Paesaggistici della Campania started up the
2
The project of Italian Cultural Heritage Portal is budgeted by the Ministero per i Beni e le Attività Culturali, It
collects some of the results obtained in the EU project Michael [MICH02], [MICH01].
14
15. project (campaniabeniculturali.i) to extend the experiment to the other cultural institutions in
Campania. For the end of 2007 the first months of 2008 we plan to extend the infrastructure
to include more than 100 nodes spread in the geographical region of Campania. This large
collection of sites will be organized in circuits, covering the territories around the main cities of
Campania, such as Benevento, Salerno, Caserta and Avellino. The cultural heritage knowledge
offering will be organized according thematic topics, such as the first civilizations in Campania,
the Roman civilization periods, the Gran tour and so on.
References & Bibliography
[ACAM07] P. Acampa, C.Noviello, Specifica OCML, Technical Sheet Octapy CMS
[AIEL06] Aiello A., M. Mango Furnari M., Massarotti A., Brandi S., Caputo V., Barone V., An experimental
Ontology Server for an Information Grid environment, Int. Journal on Parallel Programming, Dec. 2006
[BORG00] C. L. Borgaman, From Gutemberg to the global information infrastructure, MIT Press
[EDDO98] G. Eddon, H. Eddon, Distributed COM, Microsoft Press
[FURN05] M. Mango Furnari, C. Noviello, The integration of cartographic information into a Content
Management System, Proceeding of Internet Imaging VII Conference
[FURN05b] M. Mango Furnari, C. Noviello, Introduction to Octapy MapServer, http://oms.remuna.org
[GAMM95] E. Gamma et al., Design Patterns – Elements of Reusable Object-Oriented Software, Addison
Wesley
[GLUS05] R. J. Glushko, Document Engineering, MIT Press
[ICCD] Specifica ICCD, http://iccd.beniculturali.it
[KIRT99] M. Kirtland, Designing Component Based Applications, Microsoft Press
[MAPS01] MapServer Project Page, http://mapserver.gis.umn.edu/
[MICH01] Progetto MICHAEL, http://www.michael-culture.org
[MICH02] Progetto MICHAEL del Ministero per i Beni e le Attività Culturali, http://michael.beniculturali.it
[NOVI07] C. Noviello, Il Component-Model di Octapy 3, Technical Sheet Octapy CMS
15
