Object Role Modelling for Ontology Engineering in the DOGMA framework

Transcription

1 FACULTEIT WETENSCHAPPEN Vakgroep Computerwetenschappen Semantics Technology and Applications Research Lab Object Role Modelling for Ontology Engineering in the DOGMA framework STAR Lab Technical Report 2005 Peter Spyns affiliation: corresponding author: Peter Spyns keywords: ontology modelling, Object Role Modelling number : STAR date: 16/09/2005 status: final reference: Meersman R., Tari Z., Herrero P. et al., (eds.), On the Move to Meaningful Internet Systems 2005: OTM 2005 Workshops, LNCS 3762, pp Springer Verlag, 2005 Pleinlaan 2, Gebouw G-10 B-1050 Brussel Tel. +32 (0) Fax. +32 (0)

2 Object Role Modelling for Ontology Engineering in the DOGMA Framework Peter Spyns Vrije Universiteit Brussel, STAR Lab, Pleinlaan 2, Gebouw G-10, B-1050 Brussel, Belgium Abstract. A recent evolution in the areas of artificial intelligence, database semantics and information systems is the advent of the Semantic Web that requires software agents and web services exchanging meaningful and unambiguous messages. A prerequisite for this kind of interoperability is the usage of an ontology. Currently, not many ontology engineering methodologies exist. This paper describes some basic issues to be taken into account when using the ORM methodology for ontology engineering from the DOGMA ontology framework point of view. 1 Introduction A recent evolution in the areas of artificial intelligence, database semantics and information systems is the advent of the Semantic Web. An essential condition to the actual realisation of the Semantic Web is semantic interoperability, which is currently still lacking to a large extent. Nowadays, a formal representation of a (partial) intensional definition of a conceptualisation of an application domain is called an ontology [11]. The latter is understood as a first order vocabulary with semantically precise and formally defined logical terms that stand for concepts and their inter-relationships of an application domain. This paper presents some basic thoughts on how to adapt an existing conceptual schema modelling methodology called Object Role Modelling (ORM [12]) 1 for ontology engineering within the DOGMA initiative framework. The paper summarises and extends previous work at VUB STAR Lab. Early work on combining DB modelling with insights from linguistics is [32]. A more recent overview can be found in [21]. In the ontology engineering community, the importance of grounding the logical terms seems an issue rather neglected. Exceptions are researchers active at the intersection of natural language processing and ontology engineering, e.g. [4,15,22]. The paper is organised as follows. The following section (2) shortly explains how ontologies compare to conceptual data models. Subsequently section 3 presents the difference between formal and natural interpretation. Section 4 introduces the DOGMA ontology framework. In section 5, the distinctions between ORM and DOM 2 are being discussed, ORM being a conceptual data modelling methodology while DOM 2 is the DOGMA ontology modelling methodology. Section 6 contains the discussion, followed section 7 that ends the paper by outlining the future work and by giving some concluding remarks. 1 We assume that the reader is familiar with ORM. R. Meersman et al. (Eds.): OTM Workshops 2005, LNCS 3762, pp , Springer-Verlag Berlin Heidelberg 2005

3 Object Role Modelling for Ontology Engineering in the DOGMA Framework Ontologies vs. Data Models Fig. 1. ontological triangulation A data model is, in principle, tuned towards a specific application, and therefore has less or no needs for explicit semantics (since sharing is not required). The conceptual schema vocabulary is basically to be understood intuitively (via the terms used) by human developers. A conceptual schema for an application is a parsimonious model, i.e., only the distinctions (between entities, relations and characteristics) relevant for that particular application matter and are thus considered. This also applies to a global schema integrating multiple local schemas [23]. An ontology, at the contrary, is a fat model as it is, by definition, to be shared across many applications to support interoperability and, therefore, has to be broader and deeper (necessitating a larger coverage and higher granularity). Most importantly, interoperability requires a precise and formal definition of the intended semantics of an ontology (see also [17,26] for more and other details in this discussion). Alternatively, the difference can be stated in terms of the number of models possibly to comply with: one (data model) versus many (ontology) [3]. Thus, the key feature that distinguishes a conceptual data model from an ontology is the availability of definitions that unambiguously fix the intended semantics (be it only partially) of the conceptual terminology. Even in the ontology literature, authors do not always make a clear distinction between a global domain concept and a local conceptual schema term (application vocabulary see Figure 1 right lower corner). In particular, application or local ontologies are a dubious case: labels of the conceptual schema of a database are often lifted into concepts, sometimes being replaced by a synonym or orthographical variant for ease of reading and simplicity. However, without an accompanying specification of their meaning (e.g. a gloss and dictionary style definition), a shared and agreed meaning cannot be reached. A mere term cannot suffice as the understanding remains intuitive (i.e., on the linguistic level see Figure 1 left corner). As a result, the (global) conceptual and (local) language or application levels become quickly mixed up. This can particularly be harmful when aligning and merging ontologies. Only if accompanying glosses or meaning explanations are available for the terms, genuine semantic merging or alignment can be achieved (conceptual vocabulary see Figure 1 top). In case one or several database schemas have been designed on basis of an ontology, it would be natural to see that the ontology terms are used inside of the conceptual schema (global ontology [31:p.32]). The inverse scenario is to create an

4 712 P. Spyns application or local ontology [11:p.10], by extracting an ontology from a conceptual schema and defining the semantics of its terms that are promoted to concept labels (local as view e.g., [18]). An application ontology can subsequently be merged [10] with more general domain ontologies and/or other application ontologies 2. A third scenario is to use a hybrid approach combining global and local ontologies [31:p.32]. Some of these issues are already implicitly touched upon by Halpin (e.g. [12:p.74]), but he doesn t foresee any (i) mechanism to define the vocabulary and he doesn t (ii) go beyond the application at hand and its associated (or exemplary) data population when modelling. In particular, the labels denominating the object types or abstract entities are chosen at the will of the modeller. Halpin himself implicitly proves our point by explaining his usage of No. versus Nr. [12:p.42]. In our framework, an application commits to an ontology by mapping its local terminology to a selection (by the application developer) of well defined concepts (see also section 4). Not every local term may be relevant to be mapped to a global concept. 3 Natural vs. Formal Semantics Language words have acquired meaning over time (resulting sometimes in synonymy and homonymy), which is recorded in (electronic) dictionaries and thesauri. Formal terms are used in axiomatisations to reason about meaning and compute entailment. However, we concur with Farrugia who states that: Model-theoretic semantics does not pretend, and has no way to determine what certain words and statements really mean. ( ) It [= model theoretic semantics] offers no help in making the connection between the model (the abstract structure) and the real world [8:pp.30-31]. The fundamental problem is that logical theories are empty, i.e., represent mathematical structures that receive their meaning from an interpretation function that maps the logical vocabulary to (sets of) entities in the universe of discourse [9] (definition by extension). How this mapping exactly happens is open, and many models and interpretations can exist in parallel (possible worlds). In addition, Guarino has shown that an ontology deals with intension rather than with extension [11], so the question remains how the mathematical structure (c.q. ontology) receives its meaning. Our solution is to use natural language to bridge this gap. Many terminological resources already exist, mainly in technical and/or professional areas WordNet being an exception with its general language content. A shared understanding and consensuality on meaning necessarily passes through the use of natural language [18], whereby a clear distinction has to be made between the natural language vocabulary of humans and the logical vocabulary of the ontology. It means that before the formal stage of modelling can start, an informal, but even more important stage has to happen where the relevant stakeholders (i) identify the important domain vocabulary (natural language), (ii) distil the important notions and 2 One has to beware of just shifting the interoperability problem from the schema to the ontology level, thereby replacing schema integration by ontology integration.

5 Object Role Modelling for Ontology Engineering in the DOGMA Framework 713 relations from the natural language term collection, (iii) select (if available) or compose (otherwise) an informal (but clear) definition that describes as adequately as possible the intended meaning of the notion or relation aimed at and on which all the stakeholders involved agree, (iv) choose an appropriate concept or relation label (the logical term) to represent a definition, and (v) link it to the various domain terms collected that express that notion (synonyms, translations). Care has to be taken to avoid ambiguity on the conceptual level e.g., the situation or context in which a word (in a particular language) is used should resolve its polysemy [6]. The tasks mentioned above resemble very much the work of terminologists who, at least in our opinion, should become more involved in the ontology engineering process [28]. A genuine ontology engineering methodology should therefore formally include this stage in its flow just as genuine ontology infrastructure should have the necessary software tools and modules to support this. After which, the knowledge engineers can model the domain and/or application axiomatisations using most of the ORM constraints (see also [29]). 4 DOGMA: Developing Ontology Guided Mediation for Agents 4.1 The DOGMA Framework in Short VUB STAR Lab has its own ontology engineering framework called Developing Ontology Guided Mediation for Agents [18]. The original foundations of DOGMA, taking into account database modelling theory and practice [13,19] in particular ORM [12], had to be refined. Recently, the DOGMA framework has been refined to add the distinction between the language and conceptual levels by formalising the context and introducing language identifiers [6,28]. The DOGMA double articulation 3 decomposes an ontology into an ontology base (intuitive binary and plausible conceptualisations) and a separate layer, called commitment layer, of instances of explicit ontological commitments by an application (see Figure 2) [13,26]. Figure 2 illustrates that for application vocabulary, through mappings and commitment rules that impose extra constraints (e.g., uniqueness), meta-lexons (see below) are selected from a larger ontology base and as a result commits these local terms to definitions in a concept definition server (not shown). 4.2 The DOGMA Ontology Modelling Methodology (DOM 2 ) Fundamentals We propose to organise the ontology modelling process in two major steps: (i) a linguistic step and (ii) a conceptual step. The latter is subdivided in a domain and application axiomatisation phase. Note that DOM 2 still lacks aspects of distributed 3 The original notion of double articulation comes from Martinet [0: pp ] who explained how humans with a limited set of sounds (first level) are able to form meaningful elements ( subunits of words) that, in turn, can be combined to create an unlimited number of words expressing ideas (second level). In an analogous way, the ontology base contains concepts and relations (albeit potentially a very large collection) that are combined into metalexons (first level), of which particular selections are formally constraint by semantic rules (commitment rule) e.g., cardinality, mandatoriness,. to create an infinite number of interpretation variations (second level) (see figure 2).

6 714 P. Spyns collaborative modelling, which is extremely important for reaching a common agreement about meaning. We hope to draw upon existing practices from the terminology community to refine our modelling methodology on these aspects [28]. Linguistic Stage The starting point is, just as in ORM, the verbalization of information examples as elementary facts. How to get relevant material and to produce these elementary facts is not discussed here. The next step consists of transforming these elementary facts into formal DOGMA lexons: i.e., a sextuple <(γ,ζ): term 1, role, co-role, term 2 >. Informally we say that a lexon is a binary fact that may hold for some domain, expressing that within the context γ and for the natural language ζ the term 1 may plausibly have term 2 occur in role with it (and inversely term 2 maintains a co-role relation with term 1 ). As such, they correspond closely to ORM binary fact types. Lexons are independent of specific applications and should cover relatively broad domains. Experiments are carried out to extract automatically lexons from textual material [24] and to evaluate the results [30]. Fig. 2. The double articulation of a DOGMA ontology Lexons are grouped by context and language. Lexons are thus to be situated on the language level. Conceptual Stage Subsequently, the logical vocabulary is rooted in natural semantics. The meaning of the lexon constituting parts (terms and roles) is to be determined. Existing dictionaries, thesauri, or semantic networks (e.g., (Euro)WordNet) can be used. Inevitably, new definitions will have to be created. Terminological principles and practices can be taken over [14]. Labels (short hand notation) for the notions or concepts are chosen and associated with the appropriate definition and explanation. Synonyms and translations are grouped. Mappings (depending on the language and context) are defined that link natural language words (synonyms, translations) to the corresponding concept 4. All this has to happen in common agreement amongst the stakeholder involved, otherwise sharing of meaning will not be possible. After which meta-lexons are created. These are the conceptual (i.e., language and context independent) counterparts of the lexons. Conceptual relations between concepts in a particular domain are represented as binary facts and constitute the ontology base (see the lower part of Figure 2). A meta-lexon can be roughly considered as two combined (inverse) RDF triples. 4 A concept definition server that supports this functionality is being implemented in our lab.

7 Object Role Modelling for Ontology Engineering in the DOGMA Framework 715 Additional restrictions on the meta-lexons representing a specific application conceptualisation are situated in the commitment layer (see the middle part of Figure 2). This layer, with its formal constraints, is meant for interoperability issues between information systems, software agents and web services. These kinds of constraints are mathematically founded and concern rather typical DB schema constraints (cardinality, optionality etc.) as captured in the ORM constraints. They also correspond largely to OWL restrictions. By constraining meta-lexons instead of lexons, the impact of the constraints is bigger (synonyms and translations are covered). We don t present the additional steps of defining the semantic constraints here as they are straightforward for modellers familiar with ORM see [29]. 5 DOM 2 and ORM 5.1 Basic Constituents According to Halpin, a conceptual schema of a database consists of three main constituents [12:p.31]: - basic fact types: the kinds of primitive sentences or facts - constraints: the restrictions that apply to the fact types - derivation rules: rules, functions or operators (including mathematical calculation or logical inference) to derive new facts from other facts. Translated in DOGMA parlance, it means that basic fact types belong to the ontology base and that constraints belong to the commitment layer. Derivation rules are actually not considered as part of the actual ontology, in opposition to what other ontology researchers often claim. In the DOGMA framework, the derivation rules are situated in the application domain realm. Basically, inference rules use the logical vocabulary as it has been defined and constrained in the ontology. 5.2 Context and Language This is an obvious point of difference between DOM 2 and ORM as ORM does not use the notion of a context and language. As explained above, the context and language constructs are needed to map natural language terms to concepts. Currently, a DOGMA context is a mere pointer to a document (or a section in a document) in which a term appears. It is valuable to have a reference to the document containing the term in its specific context of usage. Others call this pointer the co-text [14]. Another use of contexts is to group related knowledge [25:p.184]. One can expect that lexons from the same document (or parts of it) share the same background (needed for disambiguation), and very probably will be grouped in the same context in the lexon base. Algorithms, as e.g. suggested by [15], can use the co-text for sense disambiguation of terms. As a result, a context can be formally defined as the collection of terms (including synonyms and translations) that are associated with the concepts contained by a context [5]. More research however, is still needed on this topic, especially as quite some literature is available on contexts e.g., [2]. An important distinction to be further developed is between the context of definition and the context of usage, which is important e.g. in an e-learning environment see e.g. [7]). The

8 716 P. Spyns latter leads us to the notion of pragmatics (as in the triple syntax semantics pragmatics [20]). In [27], we have preliminarily suggested the use of combined sets of commitments and called these pragmatic views to capture an overall communicative situation e.g., two intelligent agents negotiating a purchase. A context would then stand for the pragmatic situation at the ontology creation time (representing the original intended meaning) and is situated at the ontology base level, while the pragmatic views reflect a specific usage situation (not always foreseen and foreseeable) and are situated on the commitment level. A link with emergent semantics [1] can be made. However, due to space restrictions we leave this topic aside. 5.3 Reference Schemes Referencing in an ORM conceptual data model happens by means of a reference scheme. E.g., a person is identified by his first name. The actual values (or strings) for the first names are stored in the database (e.g., table Person with a column label firstname the object level of Figure 3). As ontologies, in principle, are not concerned with instances (=data, extension) but with meta-data (intension), referencing can only happen when an application has committed to the ontology (via lexical mapping rules) [33]. Databases that use different terms for the same notion can share data if their local database vocabulary (table and column labels) is mapped to the corresponding meaning in the ontology (being represented by a concept label). A reference scheme (linking a sense to a Fig. 3. Three layer reference scheme value type called data type in Figure 3) now has three levels: a value type that refers to an entity type (these two belong to the conceptual schema of the information system) that is linked to a commonly defined concept label (the latter two belonging to the ontology base level), being a short hand notation for a definition of a domain notion. Value types only appear in the application layer, when legacy systems are linked to a domain ontology. 6 Discussion Of course, there remains a number of open questions or areas for further refinement and research. Due to the space restrictions, we only mention two pending issues. It concerns first the transformation of a lexon role and co-role into a meta-lexon relationship. Do the role and co-role have to be merged into one conceptual relationship? Or do we keep two relationships and formally consider them as separate ones? Does it make sense to keep the joint combination considering the fact that RDF triples do not

9 Object Role Modelling for Ontology Engineering in the DOGMA Framework 717 consider the inverse relationship (meaning that the co-role will always be empty when importing RDF triples into the DOGMA format)? Currently, we choose to create two separate meta-lexons. A meta-lexon can be transformed to an RDF triple, if needed. In a later stage, the conversion of DOGMA commitments into Description Logic formulas that are used for consistency checking and implementing business logics (reasoning or inferencing) would benefit from this approach. Another point concerns what to do with complex concepts (e.g., hotel_name vs. airplain_manufacturing_company_name vs. name ). The question of naming conventions for complex concepts arises from the assumption that every concept refers to a piece of reality. Sometimes the meaning is felt to be too broad and some specialisation (expressed in natural language by a compound as hotel name ) is wanted. Currently, we tend to reject complex concepts, albeit it more on philosophical grounds ( notions are not to be multiplied without necessity = Occam s razor). Practice (on a case by case basis) should show if sufficient necessity is available. This echoes the point raised by Halpin about overlapping values types. 7 Future Work and Conclusion DOM 2, based on ORM, focuses specifically on how to model an application domain. Another, more encompassing ontology engineering life cycle, methodology called AKEM [34] is also under development at VUB STAR Lab. As both are complementary, the next aim is to integrate both into one overall ontology engineering lifecycle methodology. In order to consolidate and refine the new methodology, many modelling exercises should be undertaken in the future. We also plan to look into and refine linguistically based methods to automatically generate not only lexons [24,30] but also semantic constraints. In addition, the methodology still needs to be adapted for a collaborative modelling scenario. The ultimate goal is to provide the domain experts with a set of teachable and repeatable rules, guidelines and tools to standardise as much as possible an ontology engineering methodology (less art, more science). Acknowledgment This research was financed by the Flemish IWT 2001 # OntoBasis project. References 1. Aberer K., Catarci T., Cudré-Mauroux P. et al.., (2004), Emergent Semantics Systems, in, Bouzeghoub M., Goble C., Kashyap V. & Spaccapietra S.,(eds.), Proceeding of the International Conference on Semantics of a Networked World, LNCS 3226, pp Bouquet P., Giunchiglia F., van Harmelen F., Serafini L. & Stuckenschmidt H., (2004), Contextualizing Ontologies, Journal of Web Semantics, 26:: Calvanese C., De Giacomo G., Lenzerini M., (2001), A Framework for Ontology Integration, in Proceedings of the 2001 International Semantic Web Working Symposium 4. Cunningham H., Ding Y. & Kiryakov A., (2004), Proceedings of the ISWC 2003 Workshop on Human Language Technology for the Semantic Web and Web Services

10 718 P. Spyns 5. De Bo J. & Spyns P., Refining the notion of context within the DOGMA framework. Technical Report 12, STAR Lab, Brussel, De Bo J., Spyns P. & Meersman R., (2003), Creating a "DOGMAtic" multilingual ontology infrastructure to support a semantic portal. In R. Meersman, Z. Tari et al., (eds.), On the Move to Meaningful Internet Systems 2003: OTM 2003 Workshops, LNCS 2889, pp , Springer. 7. De Leenheer P. & de Moor A., Context-driven Disambiguation in Ontology Elicitation, in Shvaiko P. & Euzenat J. (eds.), (2005), Context and Ontologies: Theory, Practice and Applications: AAAI 05 Workshop, AAAI Technical Report WS-05-01, AAAI Press, pp Farrugia J., (2003), Model-Theoretic Semantics for the Web, in Proceedings of the 12 th International Conference on the WWW, ACM, pp Genesereth M. & Nilsson N., (1987), Logical Foundations of Artificial Intelligence, Morgan Kaufmann 10. Giunchiglia F., Yatskevich M. & Giunchiglia E., (2005), Efficient Semantic Matching, in Gómez-Pérez A & Euzenat J. (eds.), The Semantic Web: Research and Applications, Proceedings of the 2 nd European Semantic Web Conference, LCNS 3532, Springer, pp Guarino N., (1998), Formal Ontologies and Information Systems, in Guarino N. (ed), Proc. of FOIS98, IOS Press, pp Halpin T., (2001), Information Modeling and Relational Databases: from conceptual analysis to logical design, Morgan-Kaufmann, San Francisco. 13. Jarrar M. & Meersman R., (2002), Formal Ontology Engineering in the DOGMA Approach, in Meersman R., Tari Z. et al., (eds.), On the Move to Meaningful Internet Systems 2002: CoopIS, DOA, and ODBASE; Confederated International Conferences CoopIS, DOA, and ODBASE 2002 Proceedings, LNCS 2519, Springer Verlag, pp Kerremans, K. and Temmerman, R. (2004). "Towards Multilingual, Termontological Support in Ontology Engineering". Proceedings Workshop on Terminology, Ontology and Knowledge représentation, Lyon, France, January Magnini B., Serafini L. & Speranza M., (2002), Using NLP Techniques for Meaning Negotiation, in Proceedings of the Ottavo Convegno dell'associazione Italiana per l'intelligenza Artificiale, ( 16. Martinet A., (1955), Economie des changements phonétiques, Berne Francke 17. Meersman R., (1999), The Use of Lexicons and Other Computer-Linguistic Tools, in Zhang Y., Rusinkiewicz M, & Kambayashi Y., (eds.), Semantics, Design and Cooperation of Database Systems; The International Symposium on Cooperative Database Systems for Advanced Applications (CODAS 99), Heidelberg, Springer Verlag, pp Meersman R., (2001), Ontologies and Databases: More than a Fleeting Resemblance, In, d'atri A. and Missikoff M. (eds), OES/SEO 2001 Rome Workshop, Luiss Publications. 19. Meersman R., (2002), Semantic Web and Ontologies: Playtime or Business at the Last Frontier in Computing?, In, NSF-EU Workshop on Database and Information Systems Research for Semantic Web and Enterprises, pp Morris Ch., (1971), Writings of the General Theory of Signs, Mouton, The Hague 21. Métais E., (2002), Enhancing information systems with natural language processing techniques, Data and Knowledge Engineering 41: Navigli R. & Velardi P., (2004), Learning Domain Ontologies from Document Warehouses and Dedicated Web Sites, Computational Linguistics (2): Noy N., (2004), Semantic Integration: A Survey of Ontology-Based Approaches, SIGMOD Record Special Issue 33 [in print]

11 Object Role Modelling for Ontology Engineering in the DOGMA Framework Reinberger M.-L. & Spyns P., (2005), Unsupervised Text Mining for the learning of DOGMA-inspired ontologies, in Buitelaar P., Cimiano Ph. & Magnini B. (eds.), Ontology Learning from Text: Methods, Applications and Evaluation, IOS Press, pp Sowa, J.F. (2000) Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks Cole Publishing Co 26. Spyns P., Meersman R. & Jarrar M., (2002), Data modelling versus Ontology engineering, In, Sheth A. & Meersman R. (eds.), SIGMOD Record Special Issue 31 (4): Spyns P. & Meersman R., From knowledge to Interaction: from the Semantic to the Pragmatic Web. Technical report 05, STAR Lab, Brussel, Spyns P. & De Bo J., (2004), Ontologies: a revamped cross-disciplinary buzzword or a truly promising interdisciplinary research topic?, Linguistica Antverpiensia NS (3): Spyns P., (2005), Adapting the Object Role Modelling method for Ontology Modelling. In, Hacid M.-S., Murray N., Ras Z. & Tsumoto S.,(eds.), Foundations of Intelligent Systems, Proceedings of the 15 th International Symposium on Methodologies for Information Systems, LNAI 3488, Springer Verlag, pp Spyns P. & Reinberger M.-L., (2005), Evaluating ontology triples generated automatically from texts. In, A. Gomez-Perez & Euzenat J.,(eds.), The Semantic Web: Research and Applications, Proceedings of the 2 nd European Conference on the Semantic Web, LNCS 3532, Springer Verlag pp Stuckenschmidt H. & van Harmelen F., (2005), Information Sharing on the Web, Springer 32. van de Riet & Meersman (eds.), (1992), Linguistic Instruments in Knowledge Engineering, North Holland 33. Verheyden P., De Bo J. & Meersman R., (2004), Semantically Unlocking Database Content through Ontology-based Mediation, in Bussler C., Tannen V. & Fundulaki I. (eds.), Proceedings of the VLDB 2004 Workshops, LNCS 3372, Springer Verlag, pp Zhao G, Kingston J., Kerremans K., Coppens F., Verlinden R., Temmerman R. & Meersman R., (2004). Engineering an Ontology of Financial Securities Fraud, in Meersman R., Tari Z., Corrado A. et al. (eds.), Proceedings of the OTM 2004 Workshops, LNCS 3292, Springer Verlag, pp