Carmine Noviello Octapy3 A Distributed And Cooperative Semantic Web Oriented Cms

Uploaded on

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 …

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 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. 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

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 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 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. 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
  • 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=”” xmlns:data=”” xmlns: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=”” xmlns:data=”” xmlns: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=”” xmlns:data=”” xmlns: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=”” xmlns:data=”” xmlns: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=”” xmlns:cmf=”” xmlns:xmp=”” xmlns:base=”” 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”> </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(“”) >>> 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(“”) ....... >>> 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 : <>. @prefix rdf: <>. @prefix rdfs: <>. @prefix xsd: <>. :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 : <>. @prefix octapy: <>. @prefix rdf: <>. @prefix rdfs: <>. @prefix xsd: <>. :inv a rdfs:Property; rdfs:label “Invetory”^^<>; rdfs:domain :ArtisticObject; rdfs:range xsd:integer. :loc a rdfs:Property; rdfs:domain :ArtisticObject; rdfs:range :localization. :oss a rdfs:Property; rdfs:label “Description”^^<>; rdfs:domain :ArtisticObject; rdfs:range octapy:description. :localizzazione a rdfs:class; rdfs:label “Localization”^^<>; rdfs:subClassOf octapy:OctapyContent. :ArtisticObject a rdfs:class; rdfs:label “Artistic Object”^^<>; rdfs:subClassOf octapy:OctapyContent. @prefix : <>. @prefix contents: <>. @prefix dc1: <>. @prefix rdf: <>. 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 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 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 The network infrastructure on top of which the distributed CMS for the 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, [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, [KIRT99] M. Kirtland, Designing Component Based Applications, Microsoft Press [MAPS01] MapServer Project Page, [MICH01] Progetto MICHAEL, [MICH02] Progetto MICHAEL del Ministero per i Beni e le Attività Culturali, [NOVI07] C. Noviello, Il Component-Model di Octapy 3, Technical Sheet Octapy CMS 15
  • 16. ctapy CMS Graphic design: C.Noviello ©Copyright Istituto di Cibernetica “E.Caianiello” ©National Research Council Octapy, Octapy CMS, OMS, Octapymus are copyright by the CNR Plone and Plone CMS are copyright by the Plone Fundation Zope is a copyright by Zope Corporation All other trademarks are the property of the respective trademark owners.