, where p=all property values as parameters)
3. Architecture Overview In this section, the modules of the prototype of the DERI Semantic Web portal and their interconnection are described. We distinguish the following components in the general architecture of a Semantic Web portal: 1. Ontology management module This module allows the user to develop and instantiate ontologies providing an access to the user profile, user personalization data and the portal’s profile. In the People ’s portal prototype, this module is built employing Java and JSP as programming languages, Jena [Jena] as a Semantic Web toolkit and languages of XML/RDF/OWL family for knowledge representation. The ontology management module runs on the Tomcat server [Tomcat] and currently allows the users to extend lightweight ontologies and populate these ontologies with instances. The module can be accessed through an ordinary web browser such as Internet Explorer. 2. Publishing/delivery/personalization module This module presents the information collected by the portal to the user, i.e., this module generates the content view of the portal. Also, this module provides ontology and ontology data acquisition user interfaces. An example of is depicted at Fig. 2. Ideally, having a Semantic Web approach in mind, the work of this module should be based on employing personalization ontologies. Employing a customized content management system suitable for web-site construction is also possible for generation of content views from Semantic Web. However, the existent publishing systems that do not process ontology data pose certain limitations on the use of Semantic Web content. An example of such a limitation is the need to eventually convert Semantic Web content in a non-semantic knowledge representation format (e.g., XML file) that is supported by a typical publishing system. 3. Ontology alignment support module file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 6 von 22
An external software library for ontology alignment is being integrated in the portal environment. The criteria for choosing the library are: 1. the library written in Java 2. the library supports alignment of ontologies represented in XML/RDF/OWL languages 3. the library is preferably based on the Jena ontology model 4. the library is lightweight 5. the library’s API is understandable and preferably well documented 6. the library is open source. Among several existing libraries considered so far (namely, MAFRA Toolkit - http://mafra-toolkit.sourceforge.net Alignment API from INRIA - http://co4.inrialpes.fr/align MoA: http://mknows.etri.re.kr/moa OntoMerge: http://cs-www.cs.yale.edu/homes/dvm/daml/ontology-translation.html PROMPT plugin for Protege http://protege.stanford.edu/plugins/prompt/prompt.html), the alignment API from INRIA with encapsulated alignment algorithms is the best candidate solution according to the listed above criteria and the the integration works of this library in the portal environemnt are ongoing. This library is a product of collaboration between INRIA, University of Manchester and University of Karlsruhe. The library is written in Java, supports OWL ontologies, is based on OWL API ontology model developed by the University of Manchester, quite lightweight, has understandable API, sufficiently documented and is open source. 4. Interportal and intercommunity integration support module This module employs an access to the portals ’ profile view to the portal members provided by the publication module, interoperates with ontology alignment support module, and performs cross-application data and ontology integration tasks that can be user-driven and controlled by the user and otherwise. A general view on architecture of the portal, where the above mentioned modules are included, is depicted at Fig. 1. In the works for current prototype, the major efforts were put into modules (1) and (2), because module (1) is the core of the prototype of the Semantic Web portal, and module (2) provides user interaction and actual web-site publishing to the portal's core.
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 7 von 22
Figure 1. Conceptual architecture of Semantic Web portal
Figure 2. Technical view for user- portal interaction component: Sesame version
4. Functionality 4.1 ontology - concept "Person" The current prototype employs an ontology consisting of one concept "Person" and ca. 15 properties that are sufficient for producing and publishing a basic homepage for each DERI member. 4.1.1 ontologies employed in the prototype
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 8 von 22
The ontologies involved in the prototype were approached to the ontology specified in the SW portal ontology deliverable [Möller04]. Attention to the issue of compatibility with existing wide-spread ontologies (such as FOAF) has been payed. However, direct reuse of the portal ontology specified in the SW portal ontology deliverable [Möller04], has been found difficult because of the features: - not all the concepts/properties were found in the SW portal ontology (e.g., property for a work fax number of a person) - certain modeling solutions in the ontology proved not to be reasonable after deployment (e.g., the concept "Project" that is a subclass of the concept "Agent" and by definition acquires its properties - has acquired a property "GivesTutorials" that is senseless to instantiate in the context of the concept "Project") - not all the ontology items were modelled having a widely accepted specification as a core (e.g., "Publication" concept) In our opinion, the main reasons why these features take place are fairly straightforward: - the ontology at the time of its construction was not meant/considered to be used for portal publishing in general, and for the DERI portal publishing in particular - the ontology development approach was top-down, meanwhile the bottom-up approach (where the specific arising needs are tackled as soon as they arise) might work better. In the subsequent versions of the prototype, we plan to have a support for multiple ontologies with a commonly shared knowledgebase, so that different agents can access it in the way they know it. The support will be mostly done by the ontology alignment component. 4.1.2 ontology editing - community support The ontology instantiation part of the prototype is delivered together with a simple web-based ontology editor that allows every portal member to extend the existing ontology. The importance of ontology extension functionalities on the SW portals is in allowing the community to specify what kind of content they draw to their portal and in bottom-up growth of the quantity Semantic Web pages without which the Semantic Web is impossible [Zhdanova04]. The idea of having certain real-life actions (e.g., publishing new instances at the portal) taken place immediately can not be completely applicable to a SW portal of an organization such as DERI, because the ontology acquisition approach is novel and might invoke undesired consequences from using it inefficiently. Meanwhile it is difficult to use the approach efficiently, because of its novelty. However, in the Semantic DERI use case, the approach can be used and be helpful nevertheless by letting the users to extend the existing ontology, we learn more about user's interests and receive additional instance and ontology data that can indeed be included (probably after some conversions) in the next "stable"/publishable ontology and data versions. A view on how ontology extension editing functionality can be incorporated in user forms is presented at Screenshot 2. file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 9 von 22
Screenshot 2: Ontology editing on community portals
4.2 ontology instantiation for personal homepages Two methods out of ontology instantiation out of the four mentioned in the SW-Portal working group ontology instantiation deliverable [Siorpaes04]. Namely, instantiation in the existing prototype is performed via wrappers and via web-forms. 4.2.1 using Lixto wrapper Using LixTo wrapper, XML files containing data about all the DERI members from deri.at and deri.ie pages that list all the members were generated. The XML files for Galway and Innsbruck members had the same structure (i.e., ways to represent DERI member data), but the actually instantiated fields differ between Galway and Innsbruck members due to the differnces in presentation of the page on the DERI Galway and DERI Innsbruck websites. The XML files were converted to RDF files that are operated by the ontology manager and storage of the portal environment. Simple rules for filling in the missing data (e.g., if workCity = "Innsbruck", then workCountry = "Austria") were implemented in the XML2RDF converter. An example of the resulting RDF file for a DERI Innsbruck member is as follows:
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 10 von 22
http://www.deri.at/images/members/axel_polleres.jpg +43 512 507 9872 http://www.uibk.ac.at/~c703262 University of Innsbruck Institute of Computer Science [email protected] Polleres Innsbruck Austria +43 512 507 6486 Technikerstrasse 13 Dr. Axel Polleres A6020
An example of the resulting RDF file for a DERI Galway member is as follows: Phone: +353 091 512652 University Road
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 11 von 22
Dr. John Breslin Ireland Galway http://www.deri.ie/images/members/john_breslin.jpg +353 91 512541 http://www.johnbreslin.com [email protected] National University of Ireland Breslin
4.2.2 using forms In this subsection, we describe the form-base knowledge acquisition modules of the portal. They were designed bsing on different technologies, and in this section the functionalities and experiences are described. 4.2.2.1 Jena + file system + Java servlets + JSP Jena provides a flexible model to deal with ontologies, thus it can be seen as a helpful ontology manipulator that allows to build more advanced functionalities on top of it. Content ontology and data management: An existing low-level ontology management system that is included in Jena is exploited by the portal environment and provides an easy-to-use management facilities to all portal members. The specifics and the main effort of the ontology management module is connecting the low level ontology procedures with complex business logic, processes and operations that take place in the portal and specific adaptation to a common Web environment. Ontology and data acquisition user interfaces: Special user interfaces that are enabled to acquire ontology structures and instances from human contributors efficiently are integrated in the environment. Currently, the following ontology and data management functionalities are supported. The user is enabled via the web-browser:
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 12 von 22
- to instantiate any existing property with a literal object - to introduce a new property to any existing class in the ontology - to introduce a new subclass for any existing class in the ontology - to introduce a new class in the ontology 4.2.2.2 Sesame + MySQL + Java servlets + JSP Editing One way we followed for ontology instantiation for personal homepages is based on Java servlets, Sesame and MySQL. Hereby, Java server pages represent the front end part generating the output visible to the user while a MySQL database physically saves the date in the backend. In the middle, the Sesame system allows for communication between these two layers on a semantic level. Edit the homepage To allow for a change of the data included in a personal homepage the servlet Editor (http://c703-deri03.uibk.ac.at:8080/swportal/Editor) can be used. Based on a portal ontology schema query it lists all properties relevant for a person. If a property has the range of rdfs:Literal an input field for editing is displayed. In all other cases links are created that either allow for the editing or for the selection of the instance(s) to be the value(s) of the current property. A second query in the servlet accesses the knowledge base of the portal ontology. Wherever values of properties are available these are extracted and shown to the user. For properties that have no values assigned yet empty input fields are displayed allowing for data entry. Generality Beyond the homepage editing the servlet can be used to edit any instance conforming to the ontology schema. This means based on a parameter it can be specified of what class an instance to be edited shall be. This again allows for the output of respective input fields and also of values, if available. A further functionality also covered by the Editor servlet is the creation of new instances. This special case of editing can be triggered by calling the servlet with the parameter-value-pair [email protected] . This causes the servlet to create a timestamp and to generate a new instance id of the form . Thus, if there’s no more than one access per millisecond, it is guaranteed that each instance yields a unique id. Based on this id and the desired class respective input fields are returned and can be edited. Perspectives The current instance editor can be extended to be a class editor, too. For the case of classes the names of their properties would have to be displayed in a changeable form. Also adding, deletion and range-changing of properties would have to be supported.
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 13 von 22
Selecting A special case of ontology instantiation consists in the creation of relationships between properties on the one hand and instances that shall serve as the value for these properties on the other hand. To allow for this functionality it is necessary to list the instances of a certain class so that they can be selected as the target of such a link. The selection of a person whose homepage shall be displayed is an example of this functionality. It can be based on Java servlets, Sesame and MySQL. The servlet generates output at request time and thus no static pages have to be stored. The Sesame system serves as a middle layer and allows for data querying on a semantic level. The MySQL database is used as a central repository allowing for unified and scalable storage. Select a member The servlet Selector (http://c703 -deri03.uibk.ac.at:8080/swportal/Selector) queries the knowledge base for included people / members. In detail, an ID, the first name and the surname are extracted allowing for the creation of a link list. This list respectively includes the full name linked to the page display service. Included with this link is the ID which allows for the unambiguous selection of the member whose page is to be shown. Generality The Selector servlet as it is implemented is not restricted to listing people but can be utilized to list any instances of a given class. So for example it can also be used to select documents that are related to some person. In order to adopt to different use cases the visualization of lists supports three options. Besides the standard link list, the servlet can also output checkbox and radio button lists. This can be specified by parameters and should be based on cardinality restrictions (e.g. radio buttons for single values). Parameters Because the described tool has a very general design the special application scenario has to be specified. The parameters that allow for this are listed in the table below. Parameter name ID startclass class property type
Description The id of the instance the selected instance shall be assigned to The class of the instance the selected instance shall be assigned to The class whose instances shall be listed The URI of the property the selected instance shall be assigned to The visual style of the list (currently radio or checkbox)
Perspectives
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 14 von 22
The Selector can currently be seen as an instance selector. In the future it could be extended so to also support the listing of classes. This could be useful if the class membership of some instance shall be changed. For example a person could be specialized to a researcher using such an extended tool. 4.2.2.3 comparison of 4.2.2.1 and 4.2.2.2 methods Using Jena is preferable to using Sesame due to its flexibility and broader functionality.
4.3 ontology and instance storage for personal homepage A number of opportunities to store and manage ontologies are known [Lee04]. Two combinations were tired out in practice for maintaince of the ontologies in the prototype: Jena+filesystem and Sesame+MySQL. The user interaction component was writen in JSP+Java servlets in both cases. The technical details of a typical example of how a storage process can be executed is outlined in subsection 4.3.2. The subsection 4.3.2. follows the scenario of interaction with Sesame. While in subsection 4.3.1., the additional functionalities that are implemented with Jena and related to storage are described. 4.3.1 Jena + file system Jena provides an interface to flexible ontology management, so the toolkit is especially good for performing more complex operations than storage only as it can be done with Sesame as described in the next subsection. In this section we describe versioning and community support features of the prototype implemented with Jena. Versioning: track and record ontological and data changes that are performed on the portal by users of the People’s portal environment. The versioning functionality is supported by the versioning module. An access to versioning information is provided to the portal administrators and to the portal users and for providing help in decisions for further portal development. Versioning (ontology and tools): at the moment, the versioning Java libraries that are suitable to be plugged in and reused in the SW portal environment are not available to our knowledge. Thus, a versioning sub -module of the ontology management module is being implemented. The SemWeb Vocab Status ontology [SWstatus03] has been used to indicate whether an ontology item is "stable" or in the "testing" condition. TheSemWeb Vocab Status ontology is a small ontology that allows to relate a SW vocabulary terms to their status, and it is used at the FOAF ontology. An ontology item is marked as "stable" if it used for publishing, i.e., communicated to DERI webmasters and used to get ontology instances for the DERI website. Any new ontology items that are created by DERI members via the web-browser (see subsection 4.2.2.1) are marked with a "testing" status tag. Community support: the DERI community can extend ontologies, and see how popular (or, consensual) the proposed extensions are. The popularity is defined by the number Currently, the following versioning and community support functionalities are introduced:
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 15 von 22
The user is enabled via the web-browser - to see the status of ontology class or property - to see the popularity of ontology class or property (i.e., how many times an ontology item was instantiated by other users) In addition, a web-portal maintainer is enabled: - to see who and when when changed what ontology data, as well as what data specifically was changed (i.e., the environemnt maintains the log of user activities). An observed disadvantage of the work with filesystem vs. database is that a back up/roll back functionalities are not included there. For instance, an application can "break" a file, and experience problems with this file afterwards. 4.3.2 Sesame + MySQL Also the storage of a personal homepage can be based on Java servlets, Sesame and MySQL. The MySQL database is used as a central repository allowing for unified and scalable storage. The Sesame system serves as a middle layer and allows for ontology population on a semantic level. The servlet finally generates the output confirming the operation to the user. Save the homepage The servlet responsible for data storage is named Saver (http://c703deri03.uibk.ac.at:8080/swportal/Saver). It takes the values provided on the editing page as inputs. These are translated into RDF syntax and saved into an XML formed string. Based on the ID of the member whose data is processed the old entry in the knowledge base is removed and the new RDF string is inserted. Therefore Sesame API functions are used that can handle XML-strings as well as RDF statements. A special case to be handled are property values that are ontology instances themselves. Here we cannot include just literal values but have to refer to the respective object using the rdf:resource statement. When the storage has completed the servlet generates an HTML output in the standard portal style which presents the values that have been saved. Generality Though initially created for homepage storage the servlet can also be used to save any other ontology instance. Via parameters it has to be specified what class the instance belongs to and what id it shall be assigned. Based on this the respective RDF data can be added or changed in the knowledge base. Parameters The generality of the servlet requires further specifications to allow for concrete applications. A list of available parameters can be found below.
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 16 von 22
Parameter name Description ID The URI of the instance to be saved processed instance Perspectives Of course, the routines in the Saver servlet can also be extended to support class storage. The only major difference would be the connection to the RDFS instead of the RDF repository. 4.3.3 comparison of 4.3.1 and 4.3.2 methods In the literature, it has been demonstrated that storage and retrieval of ontologized data using Jena + file system method is somewhat more effective than using Sesame + MySQL method [Lee04]. However, at the perceptional level of the user who interacts with the prototype, we did not notice any substantial reasons (e.g., a large difference in speed of ontology data loading) of why one method should be preferred to the other.
4.4 personal homepage publishing After the ontologies can be managed and instantiated by the portal environment, it is important to provide a publishing process for the existing metadata and data. The existing prototype can support two publishing methods 1. with indirect access to ontology 2. with direct access to ontology 4.4.1 indirect access to ontology -- Jena + file system + converters + CMS When an indirect access to ontology data is used in the prototype, it is the case that ontology and ontology instance representation formats (such as RDF, RDFS) can not be directly used with conventional existing publishing technologies. This justifies by the absence of publishing environemnts that employ latest Semantic Web standards (and stable at the same time) and provide support to webmasters with coping the techniques of ontology data publishing. To support a publishing system that is based on widely accepted Web publishing standards such as XML + script language (e.g., PHP or ASP), a converter transferring the RDF instance data into XML data was created. The functionality of the converter is as follows: An RDF file like University of Innsbruck [email protected]
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 17 von 22
A-6020 Institute of Computer Science Austria Anna Innsbruck Technikerstrasse 13 +43 -512 -507-6467 Zhdanova http://homepage.uibk.ac.at/~c703261/images/anna.jpg V. +43 -512-507-9872 ...
is converted into an XML file of the following structure Anna V. Zhdanova http://homepage.uibk.ac.at/~c703261/images/anna.jpg [email protected] +43 -512 -507-6467 +43 -512-507-9872 University of Innsbruck Institute of Computer Science Technikerstrasse 13 A-6020 Innsbruck
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 18 von 22
Austria ...
using Jena. In a first version of the converter the source as well as the destination file are specified in the command line when the tool is invoked. The converter is integrated into the common prototype environment and is invoked each time when the RDF data of DERI members is changed. Thus, the The convetrter first creates a fresh RDF model with default specification and standard reification style. Then the RDF statements are read from the source file and added to the model. After reading the source data the converter writes the XML declaration
which defines the XML version and the character encoding used in the XML document to a text-output stream. In this case the document conforms to the 1.0 specification of XML and uses the UTF-8 encoding, which is the byte -oriented encoding form of Unicode. The next line written to the text-output stream describes the root element of the document. Before the end of the root element is defined and written to the textoutput stream an iterator returns all RDF statements of the model. With the help of the particular accessor functions the predicate as well as the object of each statement are extracted and subsequently written to the text-output stream in the necessary XML conform way. After writing the information to the destination file the file is closed and the program terminates. After this, the XML files can be processed by the ASP-enabled CMS [Bischof04] or PHP scripts. In the CMS editor, the ontology instance inclusion part can be carried out with the same editor as for editing the non -ontological web-page source code or choosing the web-page template. 4.4.2 Direct access to ontology The publishing of a personal homepage can be based on a direct access to an ontology. The tool Sesame for instance allows this for RDF knowledge bases and RDFS schemas. It serves as a middle layer between a Java servlet and a MySQL database and allows for querying on a semantic level. Present the page The actual homepage of a portal member is generated by a servlet named Presenter (http://c703-deri03.uibk.ac.at:8080/swportal/Presenter). Therefore it takes the ID of the user whose page is to be displayed as an input parameter. Based on this, a sesame knowledge base query is invoked, extracting all property values available for the selected member. It uses the Sesame RDF Query Language (SeRQL) whose SQL-like syntax can easily be understood. The received values are presented to the user in an appropriate style, starting with first name and surname for instance. If the respective link has been provided also a file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 19 von 22
photo of the member will be displayed. At the bottom of each homepage a link can be found which delegates the user to the page editing service. For a better visual integration into the portal the standard header and footer which are part of every portal page are included automatically. This also includes the takeover of the portal style sheet guarantying the adopting of any changes possibly carried out there. Generality The homepage presenter puts out the values of the properties of the specified member. Beyond this special case it can output property values of any instance that is specified. Thus, for example, it can also be used to present a document instance or a project instance. Parameters The Presenter servlet can be provided with parameters to specify a certain use. A described listing of them can be found in the table below. Parameter name Description ID The URI of the instance to be presented title The URI of the property to be presented as the page title table The URI(s) of the property/ies to be presented in table style subtitle The URI of the property to be presented as the page subtitle Perspectives In the future, the presenter could be extended to support classes, too. This can be useful if one wants to get to know the ontology schema. The tool would query the RDFS repository and could return the properties of a given class. This would allow for the display of the ranges of these properties, for example. 4.4.3 comparison of 4.4.1 and 4.4.2 methods Indirect publishing allows to separate the work of a webmaster and a portal engineer. Also, when used with conventional publishing technologies, is less experimental and more stable, thus might be more suitable for company/organization websites. Direct publishing can be considered as a new research field.
4.5 remote access and security A major issue in a Semantic Web Portal is to decide who is allowed to access which items (e.g. classes and instances). This is true for read access – e.g. who may look at some private data – but even more for write access. Here it has to be fixed who has the right to create new items and also who has the right to modify existing ones. Among existing ones it may also be important to determine which parts of them (e.g. which properties) are free to be changed by whom. The precondition for such restriction mechanism consists in the ability to identify the
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 20 von 22
current user. Widespread opportunities to allow for this are usernames, passwords and – based on these – also cookies. With such user accounts again it has to be decided if they can be reused from some other system or - if not – how they can be generated and transferred to the user and if they shall be modifiable by him or her respectively. To allow for security and access control in our Semantic Web Portal we mainly identified three alternative opportunities. Below we will describe them accordingly. E-Mail-Account A first approach would be to reuse the e-mail account that every DERI member owns up from the first day at the institute. The big advantage would be on the user side: No registration procedure would have to be followed and the account details should already have been memorized. An extended effort would be necessary on the system side: Because DERI passwords should not be sent unencrypted through the net the portal pages would have to be offered over the HTTP secure protocol. Portal-Account An alternative would consist in the creation of new user accounts for the portal pages. For this approach users would have to register themselves, passwords would have to be created and sent to them. Because these accounts could only be applied for the portal it might not be that necessary to protect them via encryption. Hybrid approach As a combination of the described opportunities it would also be possible to base the Portal on its own user accounts but spare the user from the registration process. This could be realized by just generating a random password and sending it to the DERI-e-mail account of each member respectively. The user name could be reused from the DERI account and thus the user only would have to memorize one new thing – namely the password. Whichever approach will be chosen, the user should have the opportunity to enter the account data only one time. By utilizing cookies, the login data should be saved on the client computer if the user allows for this. Because the user will be automatically logged in whenever he accesses the portal from the same computer, this feature should be highly appreciated. Finally the identification process will have to be completed by mapping the user account to the respective person instance in the portal ontology. This means that only people that already “exist” in the knowledge base are able to login to the portal. The advantage of this is that right after the login further information about the user – like for instance group membership – are available to the system. Based on this, the item access decisions can be made. In the worst case each property of a concept would have to be assigned by whom and in what way in may be accessed. In order to reduce this complexity access rights should be based on the ontology immanent hierarchies of users and other concepts.
5. Conclusions and Future Work file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 21 von 22
The major achievements of the performed implementation efforts are: l
l l l
l
l
l
the complete life -cycle of a DERI Semantic Web portal page from ontology design and ontology instantiation to publishing (this life-cycle was executed on the personal homepages of DERI members) integration of independently developed software in a consensual environment setting up a web server and providing a web-access to the environment different methods for the same goals were performed in practice: ¡ 2 methods for ontology construction (bottom -up and top-down) ¡ 2 methods for ontology instantiation (wrappers and forms) ¡ 2 methods to store, retrieve, manipulate ontologies and instances (Jena and Sesame) ¡ 2 methods to publish (indirect and direct access to ontology) practical and educational experience of the implementation deliverable participants: the SWP group has gained or enhanced expertise of real-life employment of (Semantic) Web tools (in particular, Jena, Sesame, LixTo, Xerces) as well as general purpose programming technologies (in particular, Java, JSP, ASP, C#, MySQL, application servers) the SWP group has gained the expertise of collaborative software development
The future work will include: l
l l
ontologizing other DERI Semantic Web portal concepts, such as Project, Publication, Event, etc providing an instantiation and publishing functionality for them integrating the two prototypes (Jena-based and Sesame-based) into one consensual system with a common knowledge base - joining functionality of both and adding multiple ontology support and restricted access option.
As far as we have got a hands-on experience with both Jena and Sesame ontology management systems, we can conclude that, probably, the focus in the future will rather be on the Jena system, even fully leaving out Sesame. This is mainly caused by Jena's high level of ontology management functions and support of the Web Ontology Language (OWL). OWL support, for instance, is necessary for specification of cardinalities of property values, which is an important extension (e.g., for ontology editing and interportal interoperation) to be included in the next version. Concerning the publishing part, the focus will probably be on indirect publishing employing XML and PHP. The major advnatages of having indirect approach are that one can keep the work of webmasters and knowledge engineers separare, and that the XML+script languages are more a secure combination for conventioanal modern browsers. However, the publishing process will be subject to change as soon as Semantic Web browsers that do not require the XML data level become widespread.
Acknowledgements The editors would like to thank all the members of the SW Portal working group for their advice and input to this document. The prototype developers would like to thank Gerold Wirnitzer and Hans Moser for help with installation and support of the
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
SW-Portal Prototype: Semantic DERI Use Case
Seite 22 von 22
server.
References [Bischof04] A CMS for DERI, 2004. URL: http://foaf.deri.at. [Jena] Jena: http://jena.sourceforge.net. [Lee04] Lee, R., 2004. Scalability Report on Triple Store Applications. SIMILE Project. URL: http://simile.mit.edu/reports/stores/. [Möller04] Möller, K., Predoiu, L., Bachlechner, D., 2004. D1 v0.1 Portal Ontology. SW-Portal Working Draft 03 August 2004. [Siorpaes04] Siorpaes, K., Prantner, K., Zhdanova, A., 2004. D13 v0.1 Ontology Instantiation. SW -Portal Working Draft 03 August 2004. [SWstatus03] SemWeb Vocab Status ontology, 2003. http://www.w3.org/2003/06/sw-vocab-status/. [Tomcat] Apache Tomcat: http://jakarta.apache.org/tomcat/index.html. [Zhdanova04] Zhdanova, A.V. "The People's Portal: Ontology Management on Community Portals". In Proceedings of the 1st Workshop on Friend of a Friend, Social Networking and the Semantic Web (FOAF'2004), 1 -2 September 2004, Galway, Ireland (2004).
$Date: Tuesday 31 August 2004 - 20:40:20$ webmaster
file://C:\Dokumente und Einstellungen\janh.NWG\Eigene Dateien\Eigene Dokumente... 02.09.2004
