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 4.1 16 April 2002: http://www.tomw.net.au/2001/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 A Common Understanding and Electronic Document Management and the Digital Library for E-commerce.
This document is intended to provide both a set of "slides" for a group presentation and notes. The notes can be read or printed for individual use. For a slide-show group presentation, set your web browser to use a large font size and the accompanying style sheet, then select the frames version of the document. The style sheet is designed to omit the notes sections of the document, which are marked with the class definition "optional" and leave a large margin before titles marked "newslide". These slides do not fit precisely on screen, but provide more flexibility than a conventional slide show.
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.
The Oxford English Dictionary describes metadata as:
metadata n., a set of data that describes and gives information about other data...
[1968 Proc. IFIP 4th Congr.: Suppl. 10 I. 113/2 There are categories of information about each data set as a unit in a data set of data sets, which must be handled as a special meta data set.] 1987 Philos. Trans. Royal Soc. A. 322 373 The challenge is to accumulate data..from diverse sources, convert it to machine-readable form with a harmonized array of *metadata descriptors and present the resulting database(s) to the user. 1998 New Scientist 30 May 35/2 With XML, attaching metadata to a document is easy, at least in theory.
Oxford English Dictionary, (Online) Draft entry Dec. 2001, URL: http://dictionary.oed.com/cgi/entry/00307096/00307096se19
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).
Ownership and Creators of the Resource |
Intellectual Content about the Resource |
Electronic or Physical Manifestation of the Resource |
Creator |
Title |
Date |
Publisher |
Subject |
Type |
Contributor |
Description |
Format |
Rights |
Source |
Identifier |
Language |
Availability |
|
Relation |
||
Coverage |
||
Function |
||
Audience |
||
Mandate |
Element have common characteristics:
Repeatable.
No limit to the length of the element value.
Any language can be used.
From: AGLS Manual, NAA (1999b)
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.
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.
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
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
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 aRefNoattribute 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 optionalFormatattribute must be assigned a value of203in place of its default value of102. If a period, rather than a single date, is to be specified theFormatattribute must be assigned a value of718.
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 optionalTypeattribute can be assigned one of the following values:
140Payment due date
203Execution date/time, requested
- If no value is
specified the value of
140will be assigned.
If a time is to be specified as a qualifier to the date the optionalFormatattribute must be assigned a value of203in place of its default value of102. If a period, rather than a single date, is to be specified theFormatattribute must be assigned a value of718.
The first occurrence of this element must specify the date of issue of the payment instruction. MOA- Monetary amount of
payment.
Defaults toGBP- Pounds sterling - for ANA. (See also restrictions imposed byINSelement.)
The optionalCurrencyattribute can alternatively be used to record the ISO 4217 code for the currency the amount is specified in (e.g.EURto 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 optionalPartyattribute should be assigned a value ofOR(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 theOfattribute:
OYOrdering customer
BEBeneficiary
- The unique EAN
assigned to the relevant party must be entered as the value of the
EANattribute.
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 compulsoryTypeattribute from the following list:
380Invoice
381Credit note
383Debit note
387Hire invoice
389Self-billed invoice
394Lease invoice
481Remittance advice
493Statement of account message
- Contents of the element are used as the reference number for the document being referenced.
<!-- 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. 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
CEN (1999) The Interim Report for CEN/ISSS XML/EDI Pilot Project, CEN/ISSS XML/EDI WORKSHOP, 2000 URL: http://www.cenorm.be/isss/workshop/ec/xmledi/documents_99/xml001_99.htm#NatPay
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
Further Information
- NEXT: XML Schema
- PREVIOUS: A Common Understanding
- The 2000 version is also available.
- Author's home page
Copyright © Tom Worthington 2000.