Int. J. Metadata, Semantics, and Ontologies, Vol. 1, No. 2, 2006
XX
A Metadata Model for E-Markets Nikos Manouselis * Informatics Laboratory, Division of Informatics, Mathematics & Statistics, Dept. of Science, Agricultural University of Athens, 75 Iera Odos str., 118 55 Athens, Greece E-mail:
[email protected] *Corresponding author
Constantina Costopoulou Informatics Laboratory, Division of Informatics, Mathematics & Statistics, Dept. of Science, Agricultural University of Athens, 75 Iera Odos str., 118 55 Athens, Greece E-mail:
[email protected]
Abstract: In the literature, there are not yet proposals about metadata models that can store the particular characteristics of e-markets, in order to facilitate users’ access to e-markets. The objective of this paper is to present a metadata model that has been particularly developed to store e-market characteristics. The proposed model is based on the Dublin Core metadata standard, and termed as the DC E-Market (DC-EM) metadata model. Such a model can allow for the description and classification of e-markets that can be useful for a variety of implementations (e.g. search engines, e-market catalogues, e-market recommendation services). This paper describes the DC-EM metadata model elements, guidelines for its encoding in the eXtensible Markup Language (XML), and a DC-EM XML record that describes an existing agricultural e-market. It also presents results from the initial implementation of DC-EM. In particular, it presents the prototype of a DC-EM metadata repository, as well as indicative results from an analysis of Greek agricultural emarkets using DC-EM. Keywords: E-markets, Dublin Core, metadata model, XML. Reference to this paper should be made as follows: Manouselis, N.. and Costopoulou, C. (2006) ‘A Metadata Model for E-Markets’, Int. J. Metadata, Semantics, and Ontologies, Vol. 1, No. 2, pp.XX–XX. Biographical notes: N. Manouselis is a PhD candidate at the Informatics Laboratory of the Agricultural University of Athens (Greece). He has a diploma in Electronics & Computer Engineering, a Master in Operational Research, as well as, a Master in Electronics & Computer Engineering, all from the Technical University of Crete (Greece). His research interests involve the design, development and evaluation of electronic services, and their applications for the agricultural sector. C. Costopoulou is an Assistant Professor at the Informatics Laboratory of the AUA. She holds a BSc in Mathematics from the National and Kapodistrian University of Athens (Greece), an MSc in Software Engineering from Cranfield Institute of Technology (UK) and a PhD from the National Technical University of Athens (Greece). Her research interests include rural area networks, Web services, intelligent agents and e-services for the agricultural sector.
1
INTRODUCTION
The online business environment is characterized by global competition, volatile demand and accelerated speed of technological changes. The role that information technology plays in today’s business activities has led to the deployment of numerous electronic markets (e-markets). In short, an e-market can be defined as a multi-party ecommerce platform intermediating between buyers and
Copyright © 2006 Inderscience Enterprises Ltd.
suppliers (Le, 2002). It is therefore an information system intended to provide its users (that is, potential market participants) with online services that will facilitate information exchange and transactions. Currently, there is a plethora of e-markets operating online. For instance, eMarket Services (http://www.emarketservices.com), which is an observatory of European business-to-business (B2B) emarkets, has listed until January 2006 about 905 e-markets from various business sectors. This plethora of e-markets
XX leads to a large amount of complex information that the potential market participants have to cope with, and which can become overwhelming for them. More specifically, tasks such as searching, locating, comparing and selecting appropriate e-markets can be difficult and time-consuming for potential market participants (Buyukozkan, 2004). Metadata is a primary tool in describing and managing information resources, and can facilitate the above tasks (Duval et al., 2002). Metadata is usually defined as data about an information source or simply ‘data about data’ (Berners-Lee, 1997). It is generally used to describe information resources, in order to facilitate their categorization, storage, search and retrieval (Miller, 1996). Metadata about an online information resource can be stored together with the actual resource (e.g. incorporated in the HTML code of the resource’s home page) or in a metadata repository (e.g. a database with descriptions). If metadata is stored in a standardised manner, it can facilitate the automation of search and retrieval mechanisms, since they can ‘understand’ the structure and values of the metadata describing a resource of a particular type. For this purpose, numerous specification and standardisation organisations around the world have been working on the development of metadata models for various business sectors. Examples include cross-domain metadata models, such as the Dublin Core (DC) standard (2004), as well as, metadata models that support metadata applications in particular domains, such as education and training (e.g. IEEE LOM, 2002; IMS CP, 2004), e-government (e.g. eGMS, 2004; AGLS, 2002), and e-business (e.g. ebXML bpPROC, 2001). In e-business domain, a metadata model for e-markets could represent and store e-market characteristics that are of interest for potential users. Thus, it can support them when searching and comparing the characteristics of different emarkets. Nevertheless, there are not yet proposals about metadata models that particularly aim at describing and classifying e-markets. Current metadata models (crossdomain or e-business particular ones) do not represent the special characteristics of e-markets and, as a consequence, they cannot facilitate to a great extent potential users that are searching for appropriate e-markets. Thus, the need for developing a specialised metadata model for e-markets can be identified. The objective of this paper is to present a metadata model that has been particularly developed to store e-market characteristics. The proposed model is based on the DC metadata standard (Dublin Core, 2004), and termed as the DC E-Market (DC-EM) metadata model. Such a model can allow for the description and classification of e-markets, facilitating online services (such as search engines, e-market catalogues or e-market recommendation services) which are deployed to support their potential users. This paper is structured as follows: section 2 provides an overview of metadata models relevant to e-markets, and identifies the need for a specialised e-market metadata model. Section 3 describes the DC-EM model structure and elements, guidelines for its encoding in the eXtensible Markup
N. MANOUSELIS AND C. COSTOPOULOU
Language (XML), and a DC-EM XML record that describes an existing agricultural e-market. It also outlines the stages of DC-EM evaluation. Section 4 presents results from the initial implementation of DC-EM. In particular, it presents the prototype of a DC-EM metadata repository, as well as indicative results from an analysis of Greek agricultural emarkets using DC-EM. Finally, section 5 presents the conclusions of this study and identifies directions for future work. 2
METADATA FOR E-MARKETS
A metadata model is a structured description about the characteristics of a type of information resources. It is a tree-like data structure that consists of metadata elements (and sometimes sub-elements) storing the characteristics of the resources. Metadata has been widely engaged in ebusiness applications, and several metadata models have been proposed to support various implementation needs. In this section, existing cross-domain and e-business metadata models are examined, in order to identify if they are appropriate for describing and categorising e-markets. Firstly, metadata models from specification and standardisation organisations are reviewed. Secondly, metadata models used in online commercial applications, such as e-market indexing and cataloguing are also introduced. 2.1
Metadata specifications and standards
There are several specification and standardisation organisations working towards the production of metadata models that can be considered relevant to e-markets. First of all, there are working groups, such as the CEN/ISSS eBusiness Standards Focus Group (http://www.cenorm.be/sh/ebiz/), which have been focusing on metadata models. These models can facilitate interoperability and reusability of the information exchange between e-business systems. The topics covered from such e-business metadata models have been so far on topics such as electronic data interchange (e.g. the Open-EDI reference model ISO/IEC 14662), classification of products (e.g. the UN/CEFACT UNSPSC product and services classification, http://www.unspsc.org/), multilingual electronic catalogues (e.g. BMEcat, http://www.bmecat.org/), e-invoicing (e.g. CEN/ISSS, 2003), and description of core business processes and messages (e.g. ebXML bpPROC, 2001). Ebusiness systems (as e-markets) can be therefore described in terms of their constituents, such as supported business processes, products offered, and e-business messages and data exchanged. Nevertheless, from our point of view existing e-business metadata models cannot be used to describe e-markets as a whole: that is, as online information resources with their own particular properties and characteristics that play a critical role when a potential user selects one e-market among others. On the other hand, there are cross-domain metadata models that aim to support the discovery of information resources.
XX A METADATA MODEL FOR E-MARKETS
Catalog Entry Role Entity Date
Alternative
Name Address Telephone E-Mail
Name Address Telephone E-Mail
Name Address Telephone E-Mail Role
Identifier
Contribute Metadata Schema Language
Identifier Title Description Source
Publisher
Creator
Contributor
Medium
Meta-Metadata
DC-EM Model
Type
Rights
Subject
Audience
Coverage
Relation
Language
Date
emResource
emTransPhase
emAgent
emFlow
emEconomicEvent
emPricing
emFunction
emSecurity
emQuality
Access Rights
emCost
Is Part Of
Has Part
Is Replaced By
Replaces
References
Created
Modified
Valid
Approach
Method
Agent
Description
Focus
Agent
Charging Scheme
Currency
Amount
Figure 1 Screenshot from the metadata repository prototype (viewing the characteristics of an e-market)
XX
N. MANOUSELIS AND C. COSTOPOULOU
These include Dublin Core (DC, 2004), MARC21 (http://www.loc.gov/marc/), TEI header (http://www.teic.org/), or MODS (http://www.loc.gov/standards/mods/). Currently, the major representative of such models for cross-domain information resource description is DC, which is an ISO standard (ISO 15836, 2003). DC consists of core elements and DC-proposed refinements of these elements. It could be considered appropriate for describing e-markets, since there are no fundamental restrictions to the types of resources to which it can be assigned. Nevertheless, the DC metadata elements are not designed to store the particular properties and characteristics of e-markets (e.g. the supported transaction phases and the types of market participants). For this purpose, further specialisation of the elements as well as their values is required, before a crossdomain model such as DC can be used for this purpose. 2.2
Online commercial applications
Apart from metadata models developed in the context of specification and standardisation organisations, metadata for e-markets are also used in software applications where emarkets are described and categorised (e.g. indexes and catalogues of e-markets). The most prominent example is the metadata model that eMarket Services is using. This model has a number of elements that the operators of eMarket Services consider as important characteristics of emarkets, including: title, URL, products and services traded, buyers and sellers, examples of buyers and sellers, geographic focus, language, e-market focus, trading functions, criteria for membership, transaction and membership statistics, owners, date established, headquarters, postal address, contact e-mail, phone, comments, and last analysed date. The model of eMarket Services stores important characteristics of an e-market but it is not a systematic and interoperable approach that covers all aspects and characteristics. A thorough e-market literature review (Manouselis, 2005) revealed that there is a number of additional characteristics that are not covered by this metadata model (such as terms of access and related costs). Other examples of e-market collection and categorisation include the Global Trading Web E-market Catalogue of Commerce One (http://www.calngi.org/applications/commerceone.html), the catalogue of B2B auctions at B2BToday.com (http://www.b2btoday.com/bb/B2B_Auctions_and_Commu nities/), and the index of e-markets provided by the Federation of International Trade Associations (http://tradelinks.fita.org/index.asp?category_id=11688&lan guage=en&parentcategory_id=10375). All these examples are only storing basic characteristics of e-markets, such as their title, URL and a short description. From a review of such online commercial applications, it has been concluded that even when a more detailed metadata model is engaged (as in the case of eMarket Services), the metadata used is usually defined ad hoc, and do not follow well-accepted metadata standards or specifications. Additionally, such commercial applications usually describe and classify e-markets using limited and
subjective metadata element sets, which are not systematically developed and tested. As a consequence, in order to describe and classify e-markets in a systematic, interoperable and reusable manner, we chose to develop a specialised metadata model that is based on a well-accepted existing one. 3
DC-EM DESCRIPTION
The development of our proposed metadata model for emarkets description and classification has been based on DC. This has been decided in order to take advantage of the fact that DC is one of the most widely applied metadata standards, and therefore existing online systems (such as search engines) can already read metadata encoded according to DC. Apart from its wide applicability, DC has been chosen due to its simple and modular structure, which makes its specialisation and/or extension more convenient. Furthermore, its implementation (e.g. using HTML or XML encoding) can be considered rather easy. To facilitate this, a large amount of related publications and supporting material (e.g. tutorials, guidelines, FAQs) are provided from http://www.dublincore.org. In addition, DC is generic enough to allow for its specialisation for the particular case of e-markets. DC-EM is a specialisation of DC that uses as many as possible of the DC elements. It proposes addition of elements only where this has been judged necessary for the particular case of e-markets’ description and classification. This section describes: (a) the elements and sub-elements of the DC-EM metadata model (Figure 1), as well as guidelines for their encoding using XML, in the light of the DC recommendations (Dublin Core, 2003), (b) an application of DC-EM for an existing e-market, and (c) the process of its evaluation. 3.1
DC-EM Elements
3.1.1 Identifier
The ‘Identifier’ element contains an unambiguous reference to the e-market under study, independent from its metadata description. It serves as a unique reference of this e-market that can be used to identify it in a set of e-markets. Even if multiple metadata records are developed for the e-market, the ‘Identifier’ element value does not change. The ‘Identifier’ element is a DC core element, used in DC-EM as recommended by DC. It can be encoded in the following way in XML: EMID0001
3.1.2 Title
The ‘Title’ element refers to the name of the e-market. Typically, it is the title by which it is formally known. It is expected to contain a text string with the title of the emarket in its original language, as well as its translations in
A METADATA MODEL FOR E-MARKETS
XX
other languages. Moreover, it can also store previous titles of the e-market, although in major changes it is recommended to develop a new metadata record. For this purpose, it also includes the following DC-proposed subelement: • Alternative: any form of the title used as a substitute or alternative to the formal title of the e-market. It can include title abbreviations as well as translations. The ‘Title’ element is a DC core element. The ‘Alternative’ sub-element is a DC-proposed refinement. They are both used in DC-EM as recommended by DC. They can be encoded in the following way in XML:
•
The ‘Publisher’ element can be encoded in XML as follows: BEGIN:VCARD N:PublisherName ADR:PublisherAddress TEL:PublisherTel EMAIL;INTERNET:
[email protected] END:VCARD
The e-market title
Alternative
title
E-mail: the electronic address of the publishing entity, represented as a text string.
of
the
e-market
(e.g. in another language)
3.1.6 Creator 3.1.3 Description
The ‘Description’ element contains a short description of the e-market content. It is stored as a free-text description so it is expected to be a text string. It is a DC core element, used in DC-EM as recommended by DC. It can be encoded in the following way in XML:
The ‘Creator’ element stores information about the entity (person or organisation) that created, and operates the emarket. It is a core element of the DC, where it is expected to store the name of the entity. In DC-EM, this element is specialised to store the following sub-elements, selected from a vCard entity (vCard, 1996):
•
Description
of
the
e-market.
• 3.1.4 Source
The ‘Source’ element includes a reference to online or physical locations where the e-market can be accessed or acquired from. For online markets, it is expected that this element will contain the current URL address of the emarket, as well as previous URL addresses of the e-market (to support the case that a user is searching for an e-market based on a URL address that has changed). It is a DC core element, used in DC-EM as recommended by DC. It can be encoded in the following way in XML: http://www.emarket.url
• •
Name: the name of the creating entity, represented as a text string. Address: the physical (postal) address of the creating entity, represented as a text string. Telephone: the telephone of the creating entity, represented as a text string. E-mail: the electronic address of the creating entity, represented as a text string.
The ‘Creator’ element can be encoded in the following way in XML: BEGIN:VCARD N:CreatorName ADR:CreatorAddress
3.1.5 Publisher
The ‘Publisher’ element contains information about the entity (person or organisation) that makes the e-market public (e.g. sponsors its publication). It is not expected to store information about the entity that has created the emarket, nor about the entity (-ies) contributing to it. It is a core element of the DC, where it is expected to store the name of the entity. In DC-EM, this element is specialised to store the following sub-elements, selected from a vCard entity (vCard, 1996): • • •
Name: the name of the publishing entity, represented as a text string. Address: the physical (postal) address of the publishing entity, represented as a text string including street, number, area, city, country etc. Telephone: the telephone of the publishing entity, represented as a text string.
TEL:CreatorTel EMAIL;INTERNET:
[email protected] END:VCARD
3.1.7 Contributor
The ‘Contributor’ element contains information about the entity (person or organisation) or entities that contribute content and/or services to the e-market. It is meant to cover entities such as content providers, technical providers, security providers, verification entities and payment transaction providers. It is a core element of the DC, where it is expected to store the name of the entity. In DC-EM, this element is specialised to store the following sub-elements, selected from a vCard entity (vCard, 1996):
XX • • • • •
N. MANOUSELIS AND C. COSTOPOULOU
Name: the name of a contributing entity, represented as a text string. Address: the physical (postal) address of a contributing entity, represented as a text string. Telephone: the telephone of a contributing entity, represented as a text string. E-mail: the electronic address of a contributing entity, represented as a text string Role: information about the role that this contributing entity has in the e-market. It is expected to contain a free-text string or to take values from a pre-defined vocabulary of business roles (e.g. ‘Content Provider’, ‘Technical Provider’, ‘Security Provider’, ‘e-Payment Provider’).
Particular attention is given to the use of ‘Role’ subelement, which stores information about the contributor’s role. The ‘Contributor’ element can be encoded in the following way in XML:
YYYY-MM-DD YYYY-MM-DD end=YYYY-MM-DD; scheme=W3CDTF
3.1.9 Type
The ‘Type’ element describes the type of the resource as well as its methodological characteristics that are useful for classification. More specifically, it uses an extension of the DCMI Type vocabulary to describe a resource as an ‘emarket’, and also includes a number of sub-elements related to economic aspects of the market participants and transactions, as well as other information related to the emarket functionality. For this, the ‘Type’ element consists of the following sub-elements: •
BEGIN:VCARD N:ContrName ADR:ContrAddress TEL:ContrTel EMAIL;INTERNET:
[email protected] ROLE:ContrRole END:VCARD
•
3.1.8 Date
The ‘Date’ element contains dates of events that are important throughout the e-market lifecycle. More specifically, it is expected to store date information relevant to the creation or availability of the e-market. It is a core element of the DC, which is replaced in DC-EM by three of its DC-proposed refinements: ‘created’, ‘modified’, ‘valid’. In DC-EM, the refined sub-elements are used as recommended by DC: • •
•
Created: the date when the e-market launched its operation. Modified: the date of an important change in the emarket operation. Typically, it is expected to store dates related with the merging of the e-market with another emarket. Valid: the period of validity of the e-market. Typically, it is expected to contain the date when the e-market ceased its operation (or ‘0000-00-00’ if the e-market has ceased its operation but at an unknown date).
The ‘created’ and ‘modified’ sub-element values are represented according to W3C-DTF (http://www.w3.org/TR/NOTE-datetime) format YYYYMM-DD. The sub-element ‘valid’ is represented using the DCMI Period notation ("end=YYYY-MM-DD; scheme=W3C-DTF"). Each sub-element can be encoded in the following way in XML:
•
•
•
•
emResource: a characterization of the exchanged resources in economic terms. It is expected to take values from a pre-defined vocabulary of terms. In DCEM implementation, these terms are based on the Resource-Event-Agent (REA) model for enterprise economic phenomena (McCarthy, 1982), as used by the ebXML technical report ‘Catalogue of Common Business Processes v1.0’ (ebXML bpPROC, 2001). After the DC-EM pilot evaluation, the list of terms was shortened to a shorter vocabulary of economic resources that can be exchanged in the particular emarket (e.g. ‘Money’, ‘Raw Materials’, ‘Labour’, ‘Services’). emTransactionPhase: a characterization of the supported phases of a transaction process. It is expected to take values from a pre-defined vocabulary of terms that are adopted from relevant literature (Grieger, 2003) (i.e. ‘Information Phase’, ‘Negotiation Phase’, ‘Settlement Phase’, and ‘After-sales Support Phase’). emAgent: a characterization of the market participants in economic terms. It is expected to take values from a pre-defined vocabulary of terms. In DC-EM implementation, these terms are based on the REA model. The list was shortened to a shorter vocabulary of economic market participants (e.g. ‘Buyer’, ‘Seller’, ‘Vendor’, and ‘Customer Service Agent’). emFlow: the type of the e-market according to the flow of products and services among the market participants. It is expected to take values from a pre-defined vocabulary of terms that are adopted from relevant literature (e.g. ‘B2B’, ‘B2C’, ‘C2C’, ‘G2B’, ‘G2C’). emEconomicEvent: a characterization of the transaction events in economic terms. In DC-EM implementation, these terms are based on the REA model. After the DCEM pilot evaluation, the list was shortened to a shorter vocabulary of economic events that take place in the particular e-market (e.g. ‘Purchase Order’, ‘Purchase’, ‘Payment’, ‘Service Call’). emPricing: a characterization of the pricing scheme that the e-market supports. It is expected to take values from a pre-defined vocabulary of terms that are adopted from relevant literature (Turban et al., 2004) (i.e. ‘Dynamic’, ‘Fixed’, and ‘Mixed’).
A METADATA MODEL FOR E-MARKETS
•
•
•
XX
emFunction: the types of functionalities offered by the e-market. It is expected to take values from a predefined vocabulary of terms that are adopted from Dai and Kauffman (2002) (e.g. ‘Public or Private Cataloguing’, ‘Public Bidding‘, ‘Private Negotiation’, ‘Internet-based Financial Services’, ‘Delivery and Logistics’, ‘Workflow Management’). emSecurity: denotes the phases of a transaction that are secured in the e-market. Recommended to be used in combination with ‘Contributor’ element, to denote the entity providing security services. It takes values from a controlled vocabulary (e.g. ‘Information Exchange Security’, ‘Ordering Security’, ‘Payment Security’). emQuality: the quality or evaluation approach followed in the e-market (e.g. a process for certifying participants or a reputation mechanism). This subelement is an abstraction of the EQO (2004) metadata model for quality approaches. It is furthermore analysed into five sub-elements: • Approach: the title or ID of applied approach. • Method: the method used, according to a predefined vocabulary of terms (e.g. ‘Benchmarking’, ‘Evaluation’, ‘Management Approaches’, ‘Quality Criteria’, ‘Standards’, ‘Certification’, ‘Accreditation Process’, ‘Quality Policy’, ‘Other’). • Agent: the agent whom the quality process concerns, taking values from a vocabulary of economic market participants in the particular emarket (e.g. ‘Buyer’, ‘Seller’, ‘Vendor’, ‘Customer Service Agent’). • Description: the textual description of quality approach. • Focus: the focus of approach, according to a predefined vocabulary (e.g. ‘Product-oriented’, ‘Process-oriented’, ‘Competency-oriented’, ‘Other’).
The ‘Type’ element is a core element of the DC, which is extended in DC-EM by nine sub-elements. It is a refinement aiming to serve the particular needs of e-markets. It can be encoded in the following way in XML: Exchanged resources
Supported
transaction
phases Participating agents Flow types
Supported
events
Pricing scheme
Description of quality approach Focus of quality approach
3.1.10 Medium
The ‘Medium’ element refers to the type of communication medium used by the e-market to facilitate transactions, such as Internet and mobile communications. It is expected to contain a free-text string or to take values from a predefined vocabulary of mediums (e.g. ‘Internet’, ‘Mobile Network’, ‘Intranet’, ‘Extranet’, ‘Phone’, ‘Fax’). It is a DCproposed refinement of the ‘Format’ core element. In DCEM, the ‘Medium’ element is used as recommended by DC. It can be encoded in the following way in XML: Network medium engaged
3.1.11 Language
The ‘Language’ element contains the language(s) in which the e-market is operating. It is not related with the language in which the metadata description is made. For instance, a Greek e-market can be operating using the Greek language, but its metadata description can be in English. The ‘Language’ element is expected to take values from a predefined vocabulary of languages, such as the ISO code set 639 (2002) (e.g. ‘en’ for English, ‘el’ for Greek). It is a DC core element, and used in DC-EM as recommended by DC. It can be encoded in the following way in XML: Language
3.1.12 Coverage
The ‘Coverage’ element includes the spatial locations that the e-market transactions cover. It is meant to reflect the physical coverage of the e-market in terms of products/services’ delivery. Typically, it will be the regions where the market participants are expected to be located. The ‘Coverage’ element is expected to take values from a pre-defined vocabulary of countries and/or regions, such as the ISO country set ISO 3166-1 (1997) as well as additional vocabulary terms to cover special cases of market coverage, such as e-markets who aim internationally or e-market systems whose coverage depends on the particular implementation (e.g. ‘USA’, ‘International’, ‘Market independent’). ‘Coverage’ is a DC core element, and used in DC-EM as recommended by DC. It can be encoded in the following way in XML:
Supported functions Coverage
Security scheme
Title
of
quality
approach
Quality method type Concerned agent type
used
3.1.13 Rights
The ‘Rights’ element stores information about the rights in and over the e-market. It is meant to reflect access rights and terms of use, as well as the corresponding costs for accessing and using the e-market. It is a core element of the
XX
N. MANOUSELIS AND C. COSTOPOULOU
DC, which in DC-EM includes the DC-proposed refinement ‘AccessRights’, and the ‘emCost’ sub-element that serves the particular needs of e-markets: •
•
AccessRights: information about who can access the emarket. It can be a textual description of access rights and restrictions. It is recommended to be based in a restricted vocabulary, describing the general access level (open/public, restricted/controlled or closed/private) of the e-market. emCost: information about the cost of accessing the emarket and its services. • Agent: the market participant whom this cost charging concerns. It is expected to take values from a pre-defined vocabulary of terms, similarly to the ‘emAgent’ sub-element of the ‘Type’ element. • Charging scheme: the charging scheme (revenue model) for the particular market participant. It is expected to take values from a pre-defined vocabulary of terms adopted by the EQO (2004) (i.e. ‘Per Transaction / use’, ‘By Subscription’, ‘Payment Once, such as entrance / registration fees’, ‘Other’). • Currency: the currency in which charging is being carried out. It is expected to take values from a predefined vocabulary of currencies, such as the currency set of ISO 4217 (2001) (e.g. ‘EUR’, ‘USD’). • Amount: the amount of charging, according to the terms of the charging scheme. It is expected to be a numerical value.
The ‘Rights’ element can be encoded in the following way in XML:
efficient, accurate classification of products and services (full vocabulary is available from http://www.unspsc.org/). The ‘Subject’ element is a DC core element, used in DCEM as recommended by DC. It can be encoded in the following way in XML:
of
charging
for
3.1.16 Meta-Metadata
The ‘Meta-Metadata’ element contains information about the metadata record that describes the e-market. It identifies the metadata record in a classification system (e.g. a database with e-market descriptions). It contains information about who provided the e-market description and when, which metadata schema was followed to produce the metadata description, and in which language the metadata is in (which can be different than the language of the e-market itself). It is an element of the IEEE Learning Object Metadata (LOM) standard (IEEE LOM, 2002). In DC-EM, it is used as recommended by IEEE LOM:
the
concerned agent
Currency
of
charging
for
the
for
the
concerned agent
Amount
of
cost
charging
concerned agent
3.1.14 Subject
The ‘Subject’ element stores information about the topics of the content of the e-market. More specifically, it stores information about the product and service types offered/exchanged. In DC-EM implementation, we used the United Nations Standard Products and Services Code (UNSPSC) of the UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business (‘Paper Materials and Products’, ‘Food Beverage and Tobacco Products’, etc.). UNSPSC is an open, global multi-sector standard for
UNSPSC
Audience type
Concerned agent Scheme
to
The ‘Audience’ element stores information about the intended audience of the e-market. It can store a textual description, but it is recommended to use a controlled vocabulary to denote the general orientation of the e-market (e.g. ‘Seller-oriented’, ‘Buyer-oriented’ or ‘Neutral’) according to the categorization proposed by Berryman et al. (2000). The ‘Audience’ element is a DC core element, used in DC-EM as recommended by DC. It can be encoded in the following way in XML:
according
3.1.15 Audience
•
Type of rights
Products/Services
•
Identifier: stores a unique label that identifies the metadata record from others in a classification system. • Catalog: the name of the classification system where the record is stored. It is expected to take a value related to the metadata catalogue or repository in which the description is stored (e.g. ‘eMaM Repository’). • Entry: the unique ID of the metadata record in the classification system (e.g. ‘eMaM0001’). Contribute: describes the entities that have contributed to the metadata record, such as the metadata author (creator) or a validator, as well as additional information about when this metadata record has been created, modified or published. • Role: the role of the entity (person or organisation) that creates, modifies or validates a metadata record. It is expected to take values from a predefined vocabulary of roles (e.g. ‘Author’, ‘Modifier’, ‘Validator’). • Entity: information about the entity. It is expected to contain a text string with the name of the person or organisation.
A METADATA MODEL FOR E-MARKETS
•
• •
Date: the date of the creation, modification or validation of the metadata record. It is expected to contain a text string where a date is denoted in the YYYY-MM-DD W3CDTF (http://www.w3.org/TR/NOTE-datetime) format (or any other widely acceptable format for date representation). Metadata Schema: contains a text string with the version of the model used (e.g. ‘DC-EM v1.0’). Language: the language of the metadata record. It is expected to take values from a pre-defined vocabulary of languages, such as the ISO code set 6391 (ISO, 2002) (e.g. ‘en’ for English, ‘el’ for Greek).
The ‘Meta-Metadata’ element can be encoded in the following way in XML: Catalog Catalog entry
XX http://www.emarket.url http://www.emarket.url http://www.emarket.url
3.2
An example
To demonstrate the use of DC-EM, an indicative example of an existing e-market is studied. The e-market under study is the GreenTrade (http://www.greentrade.net), an online marketplace that aims to contribute to the development of organic agriculture and make it possible to buy, sell and export organic agriculture supplies and products. This e-market also helps participants to communicate and gather information effectively and cheaply. The GreenTrade e-market has been studied, and its characteristics according to DC-EM have been identified. Using these characteristics, the XML metadata record in Figure 2 has been produced. An XML schema for creating and validating XML metadata records according to DC-EM has been also developed (http://e-services.aua.gr/dcem/elements/1.0/dcem.xsd).
Role of contributor Name of contributor Date of metadata contribution DC-EMv1.0 Metadata language
3.1.17 Relation
The ‘Relation’ element stores information about the relation of the e-market to other e-markets. Different types of relationships can be identified, according to whether the emarket is part of another e-market, has some other e-market as its part, has been replaced by another e-market, has replaced another e-market, or is affiliated with another emarket. The ‘Relation’ element is a core element of the DC, which is replaced in DC-EM by five of its DC-proposed refinements: • • •
• •
isPartOf: the URL of an e-market of which this emarket is a part of. hasPart: the URL of an e-market which this e-market has as its part. isReplacedBy: the URL of an e-market that has replaced the described e-market (used in combination with the ‘Date’ element, to record the date of this replacement). replaces: the URL of an e-market which this e-market has replaced at some time. references: the URL of an e-market with which this emarket is affiliated with.
The ‘Relation’ element can be encoded in the following way in XML: http://www.emarket.url http://www.emarket.url
3.3
Evaluation
The development and validation of DC-EM has followed a number of stages. First, from an e-market literature review (Manouselis, 2005) the main characteristics required for describing and classifying e-markets have been identified. Second, these characteristics have been mapped to existing DC elements, and elements’ specialisations or extensions have been introduced where necessary. Third, an initial version of the DC-EM model has been developed and tested: by two experts who have used to describe 120 emarkets from various business sectors; by 10 non-experts (post-graduate students of our department) who have used it to describe a selected sample of e-markets; and by the participants of a specialised conference on e-markets (Manouselis and Costopoulou, 2005a). Fourth, the last version of the DC-EM model has been produced, by taking into account previously identified changes/additions. 4 4.1
IMPLEMENTATION A software prototype
DC-EM can be implemented in a number of software tools that can facilitate metadata authoring and management, as well as users’ access to e-markets. An example could be a metadata repository of e-markets. Others may include online or offline tools that will allow authors to produce DC-EM metadata in HTML or XML format. Such tools will support the management of metadata records in a repository, such as importing metadata descriptions in the form of existing XML files, reviewing and validating metadata descriptions. Moreover, they will facilitate end-users when searching for e-markets, for example search engines that are able to understand embedded DC-EM metadata, online catalogues and indexes categorising e-markets according to their DCEM descriptions, and e-market recommendation services.
Int. J. Metadata, Semantics, and Ontologies, Vol. 1, No. 2, 2006 EMID0097 GREENTRADE.NET Electronic marketplace that contributes to the development of organic agriculture. http://www.greentrade.net BEGIN:VCARD N:GreenTrade ADR:8;rue du Professeur Roux;92370;CHAVILLE;FRANCE TEL:+33147500273 EMAIL;INTERNET:
[email protected] END:VCARD 2000-01-01 Money Information Negotiation Settlement Buyer Seller Vendor B2B Payment Purchase Purchase order Price quote Mixed Public or Private Cataloguing Internet en fr es International Private Buyer By subscription Seller By subscription Organic fertilizers and plant nutrients Food Beverage and Tobacco Products Chocolate and sugars and sweeteners and confectionary products Neutral eMaM Repository eMaM0097 Author Nikos Manouselis 2005-10-06 DC-EMv1.0 en
Figure 2 XML example
Copyright © 2006 Inderscience Enterprises Ltd.
XX
Int. J. Metadata, Semantics, and Ontologies, Vol. 1, No. 2, 2006 A prototype version of a DC-EM metadata repository has been implemented (http://e-services.aua.gr/eMaM.htm). Its aim is to facilitate collecting and analysing e-market descriptions. Up to now, it has been used to store more than 180 descriptions of existing e-markets. This prototype supports several functions related with searching and retrieving e-market descriptions from the repository (Figure 3). The main functions are: •
Describe e-markets, by providing an appropriate online form which a user can use to contribute e-market descriptions in the repository; Search/Browse e-markets, by providing a keyword, the user can search for e-markets, or by browsing, the user can view all e-markets in the repository that have a particular characteristic (e.g. their language is ‘Greek’ or their coverage is ‘International’); View/Edit e-market characteristics, by viewing an emarket description, the user can view/edit the full metadata record with all the characteristics of an emarket.
•
•
Figure 3 Screenshot from the metadata repository prototype (viewing the characteristics of an e-market) 4.2
A pilot usage
The DC-EM prototype can facilitate potential market participants when searching, locating, comparing and selecting appropriate e-markets. Furthermore, it can serve as a useful tool for making e-market observations. For instance, we have used DC-EM in order to examine the status of Greek agricultural e-markets (Manouselis et al., 2006). In particular, we have described 100 Greek e-markets of the agricultural sector. It has been possible to identify that most of the Greek agricultural e-markets that are operating today are also available (apart from the Greek language) in English (83%), German (10%), Italian (2%) and/or Russian (1%). Another interesting remark has been that the majority of the examined e-markets (74%) support the information phase of a transaction process, and only some of them (19%) the settlement phase. None of these emarkets supports either the negotiation phase or the aftersales phase of a transaction process. Having these
Copyright © 2006 Inderscience Enterprises Ltd.
XX observations in mind, it has been possible to produce a number of recommendations for their further development. 5
CONCLUSIONS
DC is a cross-domain metadata standard, but is not sufficient for e-market description. In this context, DC-EM is the result of the specialisation of DC, in order to produce a metadata model able to store e-market characteristics. It adopts eleven DC core elements, ten DC-proposed element refinements, and the ‘Meta-Metadata’ element from the IEEE LOM standard (2002). In order for the DC-EM elements to store e-market particular properties, specialised vocabularies of terms have been adopted where necessary (e.g. the vocabulary of terms adopted for the ‘Subject’ element, which stores information about e-market products/services). More specifically, DCEM is based on widely-accepted vocabularies and ontologies for describing the economic dimensions of an emarket. For instance, sub-elements such as ‘emEconomicEvent’, ‘emAgent’ and ‘emResource’ take values that are defined according to the REA ontology (McCarthy, 1982). In addition, its modular hierarchical structure allows for the integration of elements from other business specifications or standards, such as the description of economic business processes and documents using ebXML (http://www.ebxml.org/) and OAGIS (http://www.openapplications.org/). At its current version, DC-EM differs from such specifications in the fact that it adopts a more business-to-consumer (B2C) perspective when describing an e-market. However, in future businessto-business (B2B) specialisations of DC-EM, elements from such specifications can be used. For example, a description of the business processes that an e-market supports can be included in the ‘Type’ element, as an ‘emBusinessProc’ subelement. Such a sub-element can be speficied using the Business Process Specification of ebXML (ebXML bpPROC, 2001). DC-EM can be practically used in two ways. The first one concerns including DC-EM compatible metadata in the HTML code of the e-market home page. Such applications will support searching and finding e-markets through popular search engines. E-market operators may benefit from describing the properties of their e-markets in such a manner, since DC-based metadata can facilitate search engines that understand them (e.g. Google.com). The second one concerns the description of several e-markets in order to create a collection of structured descriptions. Such collections, similar to the eMaM metadata repository (http://e-services.aua.gr/eMaM.htm), can serve users that search for e-markets according to their particular characteristics because they have in mind the fulfilment of very specific needs. The description of e-markets upon all these multiple dimensions that DC-EM covers, allows users to search for e-markets according to the particular dimension(s) that is expected to create value for them (Lytras & Sicilia, 2005).
XX Currently, DC-EM is being specialised in order to be used for the European organic agriculture e-markets, in the context of the BIO@GRO European project (http://bioagro.aua.gr). This specialisation will be used to develop online services that will facilitate visitors of the BIO@GRO web portal when searching for appropriate emarkets of the organic agriculture sector (Manouselis and Costopoulou, 2005b). In future work, an ‘Observatory of Agricultural E-Markets’ based on this prototype implementation will be developed. Furthermore, DC-EM will be applied to describe e-markets of different business sectors. In addition, we aim at developing a data collection instrument that will be end-user friendly (e.g. an online questionnaire). The results from the evaluation of DC-EM have indicated that such an instrument can greatly facilitate the description of an e-market. ACKNOWLEDGEMENT
The work presented in this paper has been partially funded by the European Commission, and more specifically the project No EDC-11293 ‘BIO@GRO: Demonstration of an online Multilingual Biological Agriculture eServices System for Organic Farmers, Traders, Institutions and Citizens’ of the eContent Programme. REFERENCES AGLS (2002) Australian Government Locator Service Standard, http://www.naa.gov.au/recordkeeping/gov_online/agls/sum mary.html Berners-Lee (1997) ‘Realising the Full Potential of the Web’, presentation at the W3C meeting, London, 3 March 1997. Berryman, K., Harrington, L.F., Layton-Rodin, D. and Rerolle, V. (2000) ‘Electronic commerce: Three emerging strategies’, The McKinsey Quarterly, Strategy Anthology 2000, 3, pp. 129-136. Buyukozkan, G. (2004) ‘Multi-criteria decision making for emarketplace selection’, Internet Research, 14(2), pp. 139154. CEN/ISSS (2003) Report and Recommendations of CEN/ISSS eInvoicing Focus Group on Standards and Developments on Electronic Invoicing relating to VAT Directive 2001/115/EC, European Committee for Standardization CEN/ISSS. Dai, Q., Kauffman, R.J. (2002) ‘Business Models for InternetBased B2B Electronic Markets’, International Journal of Electronic Commerce, 6(4), pp.41-72. Dublin Core (2003) Guidelines for implementing Dublin Core in XML, Dublin Core Metadata Initiative (DCMI), http://dublincore.org/documents/2003/04/02/dc-xmlguidelines/. Dublin Core (2004) Metadata Element Set, Version 1.1: Reference Description, Dublin Core Metadata Initiative (DCMI), http://dublincore.org/documents/2004/12/20/dces/. Duval, E., Hodgins, W., Sutton, S. and Weibel, S.L. (2002) ‘Metadata Principles and Practicalities’, D-Lib Magazine, 8. ebXML bpPROC (2001) Catalog of Common Business Processes v1.0. ebXML Business Process Team, UN/CEFACT and OASIS.
N. MANOUSELIS AND C. COSTOPOULOU
E-GMS (2004) E-Gov Metadata Standard version 3.0. http://www.govtalk.gov.uk/schemasstandards/metadata_do cument.asp?docnum=872. EQO (2004) The EQO Model, v.1.2a, European Quality Observatory, http://www.eqo.info/files/EQO-Model1.2a.pdf. Grieger, M. (2003) ‘Electronic Marketplaces: A Literature Review and a Call for Supply Chain Management Research’, European Journal of Operational Research, 144, pp. 280294. IEEE LOM (2002) Draft Standard for Learning Object Metadata, IEEE Learning Technology Standards Committee, IEEE 1484.12.1-2002. IMS CP (2004) IMS Content Packaging Information Model: Version 1.1.4 Final Specification, IMS Global Learning Consortium, Inc. ISO 15836 (2003) Information and documentation — The Dublin Core metadata element set, International Organisation for Standardization (ISO) TC 46/SC 4 N515, February. ISO 3166-1 (1997) Codes for the representation of names of countries and their subdivisions - Part 1: Country codes Country Codes. International Organisation for Standardization (ISO), http://www.iso.org/iso/en/prodsservices/iso3166ma/index.html. ISO 4217 (2001) Codes for the representation of currencies and funds, International Organisation for Standardization (ISO), http://www.id3.org/iso4217.html. ISO 639 (2002) Codes for the Representation of Names of Languages Part 1: Alpha-2 code, International Organisation for Standardization (ISO), http://www.loc.gov/standards/iso639-2/langhome.html. ISO/IEC 14662 (2004) Information technology - Open-EDI reference model, ISO/IEC JTC 1, http://www.disa.org/international/is14662.pdf. Le, T.T. (2002) ‘Pathways to Leadership for Business-to-Business Electronic Marketplaces’, Electronic Markets, 12(2), pp. 112-119. Lytras, M.D. and Sicilia, M.-A. (2005) ‘Modeling the Organizational Aspects of Learning Objects in Semantic Web Approaches to Information Systems’, Interdisciplinary Journal of Knowledge and Learning Objects, 1, pp. 255-267. Manouselis, N. (2005) Electronic Markets: Literature review, classification, and identification of open issues, Technical Report No176, Informatics Laboratory, Agricultural University of Greece, http://e-services.aua.gr. Manouselis, N. and Costopoulou, C. (2005a) ‘Towards a Metadata Model for E-Markets’, Proc. of the 12th Research Symposium on Emerging Electronic Markets (RSEEM 2005), Amsterdam, Netherlands, 2-3 September 2005. Manouselis, N. and Costopoulou, C. (2005b) ‘Designing an Internet-based directory service for e-markets’, Information Services & Use, 25 (2), pp. 95-107. Manouselis, N., Palavitsinis, N., Costopoulou, C. and Sideridis, A. (2006) ‘Agricultural Electronic Markets in Greece: Current Status and Future Directions’, accepted for publication in Iliadis L., Batzios X., Manthou B., Salampasis M., Arabatzis G. (Eds.), Special Edition of the Hellenic Association of Information and Communication Technologies in Agriculture (HAICTA). McCarthy, W.E. (1982) ‘The REA accounting model: A generalized framework for accounting systems in a shared data environment’, Accounting Review, 57, pp. 554-578. Miller, P. (1996) ‘Metadata for the Masses’, Ariadne, 5. Turban, E., King, D., Lee, J.K. and Viehland, D. (2004) Electronic Commerce 2004: A Managerial Perspective, Prentice Hall. vCard (1996) vCard: The Electronic Business Card, Version 2.1, versit Consortium.
