Metadata for E-commerce

Tom Worthington FACS

Visiting Fellow, Department of Computer Science, Australian National University, Canberra

For: Computing 3410 Students, The Australian National University

This document is Version 2.0 25 July 2000: http://www.tomw.net.au/2000/metadata.html

Introduction

This material was prepared for the unit Information Technology in Electronic Commerce (COMP3410) at the Australian National University, semester 2, 2000. Accompanying documents discuss The Eighteen Character Problem and Electronic Document Management and the Digital Library for E-commerce.

Metadata (Data about Data) is essential for e-commerce, as it provides standard data items to allow parties to communicate about their organisations, products, terms and conditions. Also the actual payment and the "money" itself consists of data in an agreed meta-data format, in an electronic transaction. Without suitable meta-data standards, e-commerce could not take place and "money" in our online financial systems would cease to exist.

Australian Government Locator Service (AGLS) metadata standard

The Australian Government Locator Service (AGLS) metadata standard is a set of 19 descriptive elements to improve the visibility and accessibility of services and information over the Internet (NAA 2000a). The AGLS standard is based upon the Dublin Core international online resource discovery metadata standard (OCLC 2000).

The AGLS Metadata set consists of nineteen elements, in three categories:

Ownership and Creators of the Resource
Intellectual Content about the Resource
Electronic or Physical Manifestation of the Resource

In the AGLS Metadata Model each element can have a qualifier. Each element value can have a value qualifier (a controlled vocabulary or an encoding standard, and a language tag) associated with it and may be structured in some way. Qualifiers allow for more detailed description of resources.

Element have common characteristics:

Repeatable.
No limit to the length of the element value.
Any language can be used.

AGLS extends the Dublin Core's use of qualifiers to refine the semantics of the element set, and more specifically define the domain of the metadata elements. Three types of qualifiers are used:

Value Qualifiers: Indicates the use of a controlled vocabulary or externally defined standard definition. Schemes provide sets of definitions for a group of elements.
Element Qualifiers: specify relationships between resources. This is similar to the relationship between entities in entity relationship modelling or object classes in object orientated design. However, the semantics of element qualifiers are not as precisely defined in AGLS.
Value Components: specify semantic characteristics of element values and can provide a definition of a structure within the element, such as name, address, telephone number. The limitations of the AGLS syntax do not provide for the structuring of such elements found in traditional databases.

Metadata Politics

According to Cunningham (1998) AGLS was originally called "AUSGILS" and intended to be based on the U.S. Government Information Locator Service (GILS), but this was abandoned in favour of the Dublin Core metadata standard in 1997. This author's recollection differs with the proposed standard called "AGILS" for political reasons, to suggest compatabiulity with the US Government standard, with not necessalry any intention to achieve compatability (OGO 1996).

Standards politics are very important to metadata development in the real world. Few of decisions are made based on the technical merits of proposals. There are few cases where metadata standards are developed from first principles. Selections are made from existing metadata standards, based on the level of support for those standards, and the perceived importance of those organisations and individuals supporting them. Standards are then adapted, extended, made into subsets or combined.

Differences Between Metadata for DBMS and E-commerce

The term "metadata" is used by IT professionals in the design of database management systems (DBMSs). However, metadata used in e-commerce, records management or library fields tends to have a less complex structure and different use of terms:

Metadata is structured data that is used to describe resources so people searching for electronic information can find the information they are seeking more efficiently. A resource can be anything from a web page to a statue in front of Parliament House. Usually resources will either be informational documents or public services. Metadata is used to succinctly describe, manage and catalogue these resources. A metadata record consists of a set of elements (sometimes called fields or attributes) which describe different parts of a resource. For example, a metadata record describing a book may contain author, title and publisher elements. (NAA 1999b)

The Distributed Systems Technology Centre (DSTC Pty Ltd), has produced a metadata tool to create AGLS and Dublin Core metadata. Reggie, can be used to automatically generate AGLS metadata using an approved form of syntax. This is also a useful way to learn about the syntax.

Metadata Specification for Australian Business

The Business Entry Point Management Branch of Department of Employment, Workplace Relations and Small Business has extended AGLS to provide a metadata specification for government agencies making documents and services available to business (BEP 1999):

The BEP uses 17 Elements (15 from the Dublin Core, plus 2 added by AGLS). These are listed at Appendix 2.1, and defined in Appendices 3.1 - 3.17.

Some of the Elements are Mandatory, but most are Optional, and should be used only where they will materially assist users to discover the resource. Appendix 2.1 notes those that are Mandatory, and further details are provided in Appendices 3.1 - 3.17.

Some elements have Sub-Elements. A few Subelements have further Sub-Subelements. Some Subelements are Mandatory. The details are provided in Appendix 2.1 and Appendices 3.1 - 3.17.

Each Element or Sub-element may reference zero or one Schemes. The Schemes are specified in Appendices 4.1 - 4.10.

Each instance of an Element has Content, which is nominated by the Metadata-Creator as being descriptive of the resource, and is assigned in accordance with these Rules.

Examples of BEP AGLS Metadata Representation

The same metadata elements can be expressed in different formats. BEP use as examples of Dissemination Formats (BEP 1999):

UN/EDIFACT

25. At a meeting in 1990, a UN working party agreed on the following definition of UN/EDIFACT:

26. United Nations rules for Electronic Data Interchange For Administration, Commerce and Transport. They comprise a set of internationally agreed standards, directories and guidelines for the electronic interchange of structured data, and in particular that related to trade in goods and services between independent, computerized information systems.

27. Recommended within the framework of the United Nations, the rules are approved and published by UN/ECE in the (this) United Nations Trade Data Interchange Directory (UNTDID) and are maintained under agreed procedures. (UNECE 19xx)

EDIFACT is one of the two internationally cited family of standards for Elelctronic Data Interchange (EDI). The other standard is the USA's ANS X12 Syntax. In most cases the same metadata elements can be used with EDIFACT and ANS X12 (NIST 1998).

This code list is used by United States Government contracting and grant activities to indicate the data expressions that are contained herein. It is designed principally for use with Electronic Date Interchange (EDI) in either the American National Standard X12 syntax or the United Nations/Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) syntax. It may be used in other data systems as appropriate, to include as domain values for standard data schemes or as application data...

The codes in this section identify the contractor by type of business for reporting into the Federal Procurement Data System.

Note: The source for these code values is Federal Procurement Data System modified with a leading letters BT. The FPDS character is cited in the third position.

BTA
Small Disadvantaged Business Performing in the US
BTB	Other Small Business Performing in the US
BTC	Large Business Performing in the US
BTD	Javits-Wagner-O'Day Act (JWOD) Participating Nonprofit Agencies
BTF	Hospital
BTL	Foreign Concern/Entity
BTM	Domestic Firm Performing Outside US
BTU	Historically Black Colleges and Universities or Minority Institutions
BTV	Other Educational
BTZ	Other Nonprofit

Standards exist for electronic versions of commonly used business forms, such as invoices and Remittance Advice (NIST 1999):

810 Invoice - Updated in January 1996 and published as NIST Special Pub 881-10 - ( ASCII, RTF, or PDF ) - Version Control Number: 003040FED01A regenerated as 003040F810_0.
820A Payment Order/Remittance Advice (Automated Standard Application for Payments): Version Control Number 003040F820A1 - updated April 20, 1999 - ( PDF, ASCII, RTF

Example: VICS EDI

An example of e-commerce in use is the Voluntary Interindustry Commerce Standard (VICS EDI) which is a subset of the ANSI ASC X12 national standard. VICS EDI is used in the USA in the retail industry between retailers and suppliers (UCC 2000).

The VICS EDI implementation guidelines contain transaction sets, including Financial transactions. A set of examples of transactions have been prepared to assist with understanding and implementation, including Financial transactions. One example is a combined payment order and remittance advice (UCC 1999):

Business Scenario:

The payer is initiating payment and remittance advice to the payee's financial institution. The method used in this example to move the payment and the remittance is the ACH CTX format.

The current trend is to express the same metadata as used in forms or business transactions, but in XML based syntax, rather than EDIFACT, ANS X12 or other syntax. Two examples are:

Extensible Forms Description Language (W3C 1998):

This document describes an XML syntax for the Extensible Forms Description Language (XFDL). The purpose of XFDL is to solve the body of problems associated with digitally representing complex forms such as those found in business and government. The requirements include support for high precision layout, supporting documentation, integrated computations and input validation, multiple overlapping digital signatures, and legally binding auditable transaction records, by maintaining the whole form as a single unit such that digital signatures can capture the entire context of transactions.
XML-EDI (CEN 2000):

XML/EDI's aim is to use the know-how of business processes, captured in EDI messages, but tries to put it in a Web environment, whereby the same file can be viewed by a user or can be processed by an application. Rather then having HTML for a user and UN/EDIFACT for an application, with XML/EDI you can have an EDI message that can be an UN/EDIFACT orders message written in an XML format; therefore it is presentable to the application just like the EDI file. The same file uses the embedded templates and rules that explain how it should be displayed to a user and can be viewed through a browser.

The idea behind the whole initiative is that in terms of a workflow application, one can send an EDI message in an XML format to a supplier who can then pick it up and present it through a browser to a person who is in charge of approving incoming orders. That person can add some data to the incoming order, which actually signals his approval - this could for instance be a digital signature. The approved order can then be sent into the supplier's application as a plain EDI file. In this way, as a human or an application creates a message, it can travel through an organisation, and can be sent to another organisation and switch between humans and applications also. Every time the XML file will become larger, containing new updated information and as such it is almost a foundation for a workflow application.

Example of XML/EDI: Payment Order

The Interim Report for CEN/ISSS XML/EDI Pilot Project give the example of an XML version of an EDIFACT National Payment Order (CEN 1999):

<?xml version="1.0"?>
<!DOCTYPE PAY-NAT SYSTEM "pay-nat.dtd">
<PAY-NAT RefNo="0005">
<BGM>AA124</BGM>
<DTM1>19980812</DTM1>
<DTM1 Type="203">19970815</DTM1>
<MOA>100</MOA>
<FII Party="OR">
<UKB>010344</UKB>
<ACC>23412345</ACC>
<ACN>MR N SMITH</ACN>
</FII>
<FII Party="BF">
<UKB>010344</UKB>
<ACC>01341234</ACC>
<ACN>MR N WHITE</ACN>
</FII>
<NAD Of="OY" EAN="5012345678900"/>
<PRC>
<DOC& Type="380"gt;AA123</DOC>
</PRC>
</PAY-NAT>

The XML elements used are:

PAY-NAT: Container for the message segments required for a national payment instruction.
Note: A national payment instruction does not normally involve currency exchange.
May optionally have a RefNo attribute that identifies the sequence of the message within a larger interchange.
BGM: Identifies the beginning of the message.
Contents of the element are used as the reference number for the message.
DTM1: Date of message, in ISO 8601 format.
If a time is to be specified as a qualifier to the date the optional Format attribute must be assigned a value of 203 in place of its default value of 102. If a period, rather than a single date, is to be specified the Format attribute must be assigned a value of 718.
The first occurrence of this element must specify the date of issue of the payment instruction.
DTM2: Date of payment, in ISO 8601 format.
The optional Type attribute can be assigned one of the following values:

140 Payment due date
203 Execution date/time, requested

If no value is specified the value of 140 will be assigned.
If a time is to be specified as a qualifier to the date the optional Format attribute must be assigned a value of 203 in place of its default value of 102. If a period, rather than a single date, is to be specified the Format attribute must be assigned a value of 718.
The first occurrence of this element must specify the date of issue of the payment instruction.
MOA: Monetary amount of payment.
Defaults to GBP - Pounds sterling - for ANA. (See also restrictions imposed by INS element.)
The optional Currency attribute can alternatively be used to record the ISO 4217 code for the currency the amount is specified in (e.g. EUR to indicate an amount in Euros).
FII: Container for financial institution information.
When details of a bank other than that of the beneficiary are being provided the optional Party attribute should be assigned a value of OR (Ordered bank).
UKB: Compulsory UK bank branch sort code of institution.
Note: The fixed values for the attributes associated with this element require that the value be entered according to the rules laid down for the UK by the Association of Payment Clearing Services.
ACC: Compulsory account number.
ACN: Optional account holder name.
NAD: Name and address of any non-financial institutions (the buyer and the seller of the good for which payment is being made) associated with payment order.
The role played by the identified organization must be indicated by the use of one of the following values for the Of attribute:

OY Ordering customer
BE Beneficiary

The unique EAN assigned to the relevant party must be entered as the value of the EAN attribute.
Optionally name and address details can be added as a set of <NAD-LINE> elements within the address element to assist printing of the document.
PRC: Optional container for details of documents that are associated with the process.
DOC: Reference document against which payment is being made.
The compulsory Type attribute from the following list:

380 Invoice
381 Credit note
383 Debit note
387 Hire invoice
389 Self-billed invoice
394 Lease invoice
481 Remittance advice
493 Statement of account message

Contents of the element are used as the reference number for the document being referenced.

The XML document type definition defining of this message is:

<!-- SIMPL-EDI Message Type for National Payment Orders -->
<!-- XML Document Type Definition created by The SGML Centre
     Last Updated: October 1998
     -->
<!-- Note: Element names in this version of the DTD are constrained
           to be non-significant (i.e. have no integral semantic meaning).
           Element names are, therefore, based on the alphanumeric
           identifiers assigned to the equivalent information in the
           EDIFACT messages defined in the SIMPL-EDI report dated
           12th May 1998.
     -->
<!-- Note: Attributes with FIXED values should not be used in messages.
           Such attributes are provided in the DTD simply to record the
           mapping between XML and EDIFACT versions of SIMPL-EDI orders.
     -->

<!ELEMENT PAY-NAT      (BGM, DTM1, DTM2, MOA, FII*, NAD*, PRC?) >
<!ATTLIST PAY-NAT
          UN-EDIFACT:Prefix    CDATA   #FIXED                "UNH"
          RefNo                CDATA                         #IMPLIED
          MessageTypeID        CDATA   #FIXED                "PAYEXT"
          Version              CDATA   #FIXED                "D"
          ReleaseNumber        CDATA   #FIXED                "96A"
          Agency               CDATA   #FIXED                "UN"
          AssociationCode      CDATA   #FIXED                "SIMP01"   >

<!ELEMENT BGM        (#PCDATA) >
<!ATTLIST BGM
          UN-EDIFACT:Prefix    CDATA   #FIXED                "BGM"
          Type                 CDATA   #FIXED                "451"
          Agency               CDATA   #FIXED                "136"      >

<!ELEMENT DTM1       (#PCDATA) >
<!ATTLIST DTM1
          UN-EDIFACT:Prefix    CDATA   #FIXED               "DTM"
          Type                 CDATA   #FIXED               "137"
          Format               (102|203|718)                "102"
          MaxOccurs            CDATA   #FIXED               "10"       >

<!ELEMENT DTM2       (#PCDATA) >
<!ATTLIST DTM2
          UN-EDIFACT:Prefix    CDATA   #FIXED               "DTM"
          Type                 (140|203)                    "140"
          Format               (102|203|718)                "102"
          MaxOccurs            CDATA   #FIXED               "10"       >

<!ELEMENT MOA       (#PCDATA) >
<!ATTLIST MOA
          UN-EDIFACT:Prefix    CDATA   #FIXED       "MOA"
          Type                 CDATA   #FIXED       "9"
          Currency             CDATA                "GBP"                 >

<!ELEMENT FII       (UKB, ACC, ACN?) >
<!ATTLIST FII
          UN-EDIFACT:Prefix    CDATA   #FIXED             "FII"
          Party                (BF|OR)                    "BF"
          MaxOccurs            CDATA   #FIXED             "4"             >

<!ELEMENT UKB       (#PCDATA) >
<!ATTLIST UKB
          List                 CDATA   #FIXED             "154"
          Agency               CDATA   #FIXED             "133"           >

<!ELEMENT ACC       (#PCDATA) >

<!ELEMENT ACN       (#PCDATA) >

<!ELEMENT NAD       (NAD-LINE*) >
<!ATTLIST NAD
          UN-EDIFACT:Prefix    CDATA   #FIXED             "NAD"
          Of                   (OY|BE)                    #REQUIRED
          EAN                  CDATA                      #REQUIRED
          Agency               CDATA   #FIXED             "9"
          MaxOccurs            CDATA   #FIXED             "6"             >
<!-- Note: The EAN has been treated as a required attribute, rather than
            data, because it is presumed that a list of valid entries will
            be presented to the user by each system.
     -->

<!ELEMENT NAD-LINE  (#PCDATA) >

<!ELEMENT PRC       (DOC+) >
<!ATTLIST PRC
          UN-EDIFACT:Prefix    CDATA   #FIXED             "PRC"
          Type                 CDATA   #FIXED             "8"             >

<!ELEMENT DOC       (#PCDATA) >
<!ATTLIST DOC
          UN-EDIFACT:Prefix    CDATA   #FIXED             "DOC"
          Type                 (380|383|381|387|
                                389|394|481|493)          #REQUIRED
          MaxOccurs            CDATA   #FIXED             "9999"          >

This is a reasonably readable example. There are also proposals for using natural language attribute names, rather than abbreviations (CEN 1999). However, there is a bewildering array of such proposed standards. Also commercial vendors of electronic document and e-commerce products use variations of standards, draft proposed standards, or attempt to create defacto standards based on market dominance.

References

Cunningham, A. (1998) Enabling Seamless Online Access to Government, National Archives of Australia, 1998, URL: http://www.naa.gov.au/recordkeeping/gov_online/agls/Metadata_paper22sept98.html
BEP (1999) Metadata Specification for BEP, Business Entry Point Management Branch of Department of Employment, Workplace Relations and Small Business, 1999, URL: http://about.business.gov.au/bep/agencies/provinfo/metadata/metadata.htm
CEN (1999) The Interim Report for CEN/ISSS XML/EDI Pilot Project, CEN/ISSS XML/EDI WORKSHOP, 2000 URL: http://www.tieke.fi/ovt/xml/interim.htm#NatPay
CEN (2000) Recommendations for standardization in the field of XML for electronic data interchange, CEN/ISSS XML/EDI WORKSHOP, 2000 URL: http://forum.afnor.fr/afnor/WORK/AFNOR/GPN2/XMLEDI/PUBLIC/DOC/2000/042.doc
NAA (2000a) The Australian Government Locator Service: Summary, National Archives of Australia, Commonwealth of Australia, 2000, URL: http://www.naa.gov.au/recordkeeping/gov_online/agls/summary.html
OCLC (2000) The Dublin Core Metadata Initiative, OCLC Online Computer Library Center, Inc., 2000, URL: http://purl.oclc.org/dc/
OGO (1996) Architecture For Access To Government Information, Information Management Steering Committee Technical Group, Office of Government Information Technology, 1996 URL: http://www.defence.gov.au/imsc/imsctg/imsctg1c.htm#RTFToC87
NAA (1999b) AGLS Manual, Version 1.1, National Archives of Australia, Commonwealth of Australia, 1999, URL: http://www.naa.gov.au/recordkeeping/gov_online/agls/user_manual/overview.html#s21
NIST (1998) Federal Procurement Code List One (FP1), National Institute of Standards and Technology, 1998 URL: http://snad.ncsl.nist.gov/dartg/edi/fededi-coding.html
NIST (1999) Federal Procurement Code List One (FP1), National Institute of Standards and Technology, 1999 URL: http://snad.ncsl.nist.gov/dartg/edi/3040-ic.html
UCC (1999) UCC: Voluntary Interindustry Commerce Standard (VICS EDI), Uniform Code Council, Inc., 2000 URL: http://www.uc-council.com/e_commerce/ec_voluntary_interindustry_com.html
UCC (2000) VICS EDI - Business Examples - Financial Set, Uniform Code Council, Inc., 1999 URL: http://www.uc-council.com/documents/pdf/finance.pdf VICSEDI BusinessExamples--FinancialSet http://www.uc-council.com/documents/pdf/finance.pdf
UNECE (19xx) UN/EDIFACT DRAFT DIRECTORY, United Nations Trade Division, 19xx URL: http://www.unece.org/trade/untdid/welcom1.htm
W3C (1998) Extensible Forms Description Language (XFDL), W3C, 1998 URL: http://www.w3.org/TR/NOTE-XFDL