Today, the World Wide Web is a global informationrepository of resources primarily consisting of syntactically-structuredHTML documents and MIME-typed files. These relatively unstructured datamodels do not provide the foundation for command and control situationmodeling or enterprise computing, or for a new generation of tools to operateon a more semantically-structured, knowledge-based web. Richer base datamodel(s) are needed that converge the benefits of emerging Web structuringmechanisms and distributed object service architectures.
A number of ongoing activities are attempting to merge aspects of objectmodels with those of the World Wide Web. This paper describes a numberof these activities, with particular emphasis on those which focus on providingenhanced facilities for representing metadata for describing Web (and other)resources. The intent of this paper is to:
Many business and governmental organizations are planning or developingenterprise-wide, open distributed computing architectures to support theiroperational information processing requirements. Such architectures generallyemploy distributed object middleware technology, such as the Object ManagementGroup's (OMG's) Common Object Request Broker Architecture (CORBA) [OMG95],as a basic infrastructure.
The use of objects in such architectures reflects the fact that advancedsoftware development increasingly involves the use of object technology.This includes the use of object-oriented programming languages, class librariesand application development frameworks, application integration technologysuch as Microsoft's OLE, as well as distributed object middleware suchas CORBA. It also involves the use of object analysis and design methodologiesand associated tools.
This use of object technology is driven by a number of factors, including:
The first two factors reflect requirements for business systems to berapidly and cheaply developed or adapted to reflect changes in the enterpriseenvironment, such as new services, altered internal processes, or alteredcustomer, supplier, or other partner relationships. Object technology providesmechanisms, such as encapsulation and inheritance, that have the potentialto support more rapid and flexible software development, higher levelsof reuse, and the definition of software artifacts that more directly modelenterprise concepts.
The third factor reflects a situation faced by many large organizations,in which a key issue is not just the development of new software, but thecoordination of existing software that supports key internal processesand human activities. Mechanisms provided by object technology can helpencapsulate existing systems, and unify them into higher-level processes.
The fourth factor is particularly important. It reflects the fact that,as commercial software vendors incorporate object concepts in key products,it will become more and more difficult to avoid using object technology.This is illustrated by the rapid pace at which object technology is beingincluded in software such as DBMSs (including relational DBMSs) and othermiddleware, and client/server development environments. Due to this factor,organizations may be influenced to begin adopting object technology beforethey would ordinarily consider doing so.
At the same time, the Internet is becoming an increasingly important factorin planning for enterprise distributed computing environments. For example,companies are providing information via World Wide Web pages, as well ascustomer access via the Internet to such enterprise computing servicesas on-line ordering or order/service tracking facilities. Companies arealso using Internet technology to create private Intranets, providingaccess to enterprise data (and, potentially, services) from throughoutthe enterprise in a way that is convenient and avoids proprietary networktechnology. Following this trend, software vendors are developing softwareto allow Web browsers to act as user interfaces to enterprise computingsystems, e.g., to act as clients in workflow or general client/server systems.Products have also been developed that link mainframes to Web pages (e.g.,translating conventional terminal sessions into HTML pages).
Organizations perceive a number of advantages in using the Web in enterprisecomputing. For example, Web browser software is widely available for mostclient platforms, and is cheaper than most alternative client applications.Web pages generally work reasonably well with a variety of browsers, andmaintenance is simpler since the browser and associated software can reducethe amount of distributed software to be managed. In addition, the Webprovides a representation for information which
However, as organizations have attempted to employ the Web in increasingly-sophisticatedapplications, these applications have begun to overlap in complexity thesorts of distributed applications for which architectures such as OMG'sCORBA, and its surrounding Object Management Architecture (OMA) [OMG97]were originally intended. Since the Web was not originally designed tosupport such applications, Web application development efforts increasinglyrun into limitations of the basic Web infrastructure. As a result, numerousefforts are being made to enhance Web capabilities, to enable them to supportthese more complex applications. In order to understand the missing elements,it is useful to look at the components of OMG's OMA.
There is increasing agreement that modeling a distributed system asa distributed collection of interacting objects provides the appropriateframework for use in integrating heterogeneous, autonomous, and distributed(HAD) computing resources. Objects form a natural model for a distributedsystem because, like objects, distributed components can only communicatewith each other using messages addressed to well-defined interfaces, andcomponents are assumed to have their own locally-defined procedures enablingthem to respond to messages sent them. Objects accommodate the heterogeneousaspects of such systems because messages sent to distributed componentsdepend only on the component interfaces, not on the internals of the components.Objects accommodate the autonomous aspects of such systems because componentsmay change independently and transparently, provided their interfaces aremaintained. These characteristics allow objects to be used both in thedevelopment of new components, and for encapsulating access to legacy components.In addition, because object-oriented implementations bundle data with relatedoperations in modular units, the use of objects provides the possibilityof fine-grained tuning in the computing architecture by moving or copyingobjects to appropriate nodes of the network (this is becoming increasinglyfeasible with the development of technology such as Sun's Java).
OMG's Object Management Architecture (OMA) is an example of a distributedobject architecture intended to support distributed enterprise computingapplications. The OMA includes the following components:
These components provide multiple levels of capabilities in supportof developing complex distributed applications.
The ORB in the OMA is defined by the CORBA specifications. An ORB doesnot require that the objects it supports be implemented in an object-orientedprogramming language. The CORBA architecture defines interfaces for connectingcode and data to form object implementations, with interfaces definedby IDL, that are managed by the ORB and its supporting object services.It is this flexibility that enables ORBs to be used in connecting legacysystems and data together as components in enterprise computing architectures.
A distributed enterprise object system must provide functionality beyondthat of simply delivering messages between objects. OMG's Object Serviceshave been defined to address some of these requirements. Object Servicesprovide the next level of structure above the basic object messaging supportprovided by CORBA. The services define specific types of objects (or interfaces)and relationships between them in order to support higher-level capabilities.Object Services currently defined by OMG include, among others:
Taken together, OMG Object Services provide services for ORB-accessibleobjects similar to those that an Object DBMS (ODBMS) provides for objectsin an object database (queries, transactions, etc.). The Object Services,together with the basic connectivity provided by the ORB, turn the collectionof network-accessible objects into a unified shared object space,accessible by any ORB client application. Managing the collection of ORB-accessibleobjects thus becomes a generalized form of "object database management",with the ORB being part of the internal implementation of what is effectivelyan ODBMS. Viewed in this way, the OMA provides a powerful object-orientedinfrastructure for the development of general-purpose applications, justas an enterprise database and its associated DBMS provide such an infrastructurefor the development of general-purpose enterprise applications. Additionallevels of organization are also needed. These additional levels are whereOMG's Common Facilities, Application, and Domain Objects, as well as stillhigher level concepts, come into play [MGHH+97].
If the Web is to be used as the basis of complex enterprise applications,it must provide generic capabilities similar to those provided by the OMA,although these may need to be adapted to the more open, flexible natureof the Web. Providing these capabilities involves addressing not only theprovision of higher level services and facilities for the Web, but alsothe suitability of the basic data structuring capabilities provided bythe Web (its "object model"). For example, in the case of services,search engines (a form of query service) are becoming indispensable tools,and agent technology can add additional intelligence to the searching process.Similarly, extended facilities to support transactions over the Web arebeing investigated. However, the ability to define and apply powerful genericservices in the Web, and the ability to generally use the Web to supportcomplex applications, depends crucially on the ability of the Web's underlyingdata structure to support these complex applications and services.
The basic data structure of the Web consists of hyperlinked HTML documents.It is generally recognized that HTML is too simple a data structure tosupport complex enterprise applications. For example, Jon Bosak's XML,Java, and the Future of the Web [Bos97] identifies a number of keylimitations of HTML:
These limitations severely affect the ability to develop advanced applicationsusing HTML, including:
Proprietary HTML extensions have been developed to address some of theseproblems, but none deals with all of them, and together they create barriersto interoperability. The same is true of the proprietary data formats usedby particular applications. Their use requires specialized helper applications,plug-ins, or Java applets, creating interoperability problems, and difficultyin reusing that data in different applications for new purposes. Whileuse of some specialized formats is necessary in particular applications(e.g., multimedia), in many cases these formats are just used to addressthe deficiencies of HTML for generalized document and data processing.
A more fundamental direction of efforts to address HTML limitationshas been attempts to integrate aspects of object technology with the basicinfrastructure of the Web. There are a number of reasons for the interestin integrating Web and object technologies:
Such efforts all contribute toward giving the Web a richer structuralbase, capable of directly supporting a wider variety of activities, inmore flexible and extensible ways. However, up until recently these effortshave still been based on HTML, with its basic structuring limitations,and have generally been pursued as separate, non-integrated activities.There is much other ongoing work within both the Web and database communitieson data structure developments to address Web-related enhancements. Workon similar issues is ongoing within the Object Management Group as well(see Section 2.4). This work has contributed valuable ideas, and the variousproposals illustrate similar basic concepts, generally, movement towardsome form of simple object model. However, these similarities are oftenobscured by detailed representational differences, and the work is fragmentedand lacks a unifying framework. As a result, individual proposals oftenlack key capabilities that are in some cases contained in other proposals.Moreover, in many cases these proposals are not well-integrated with keyareas of emerging industry consensus on Web data structuring technologies.
If the Internet is to develop to support advanced application requirements,there is a need for both richer individual data structuring mechanisms,and a unifying overall framework which supports heterogeneous representationsand extensibility, and provides metalevel concepts for describing and integratingthem.
The intent of this paper is to describe how a number of (in some respects)separate "threads" of Web-related development can be combinedto form the basis of a Web object model to address these requirements.This combination is based on the observation that the fundamental componentsof any object model are:
As a result, what is needed to progress toward a Web object model is:
At the same time, the openness of the Web compared to conventional objectmodels needs to be preserved, due to the distinct requirements of the Webenvironment for openness and scalability.
In the following sections, this paper will:
As noted in the Introduction, there has been much ongoing work on enhancementsto address Web limitations in supporting richer data structures, and integratingobject technology. For example, the Internet and Web communities have developedboth additional representations, and a number of "object models"or data structuring principles, to represent richer data structures. Thedatabase community has also developed proposals for "lightweight objectmodels," partly driven by attempts to represent the structure of Webresources. All this work has contributed valuable ideas and, taken as awhole, exhibits important common underlying principles. What is requiredis that this work be integrated, and the best ideas merged.
The Introduction specifically noted that what is needed to progresstoward a Web object model is:
This section describes a number of the key technologies that attemptto address parts of these problems. Several of these technologies willbe used as the basis of an approach, described in Section 3, which integratesthem to support a Web object model.
The following subsections describing the various technologies are insome cases rather long, and include a great deal of text and specific examplestaken from the cited references. The purpose in doing this is to provideenough detail in one place to illustrate key concepts and the roles theymight play in supporting a Web object model, and to give the reader a feelfor how generalizations of the concepts might be developed. Hence, thisreport makes no claims of originality for most of this material (and readersshould refer to the cited sources for further details). The subsectionsalso include some additional commentary highlighting key points, and establishing"forward references" to later material.
Several of the sections describe ongoing activities of the World WideWeb Consortium (W3C), particularly:
The reader should be aware that in many cases these specifications areworks in progress. As a result, some of the details described in this report,as well as the source references, may no longer be completely accurate(or accessible due to changed URLs) by the time the report is read. Thelatest information on these activities can be obtained through the mainW3C Web page <http://www.w3.org/>or W3C's technical report page <http://www.w3.org/TR/>.
The Introduction briefly described HTML's limitations in supportingthe data structure requirements of more complex Web applications. HTMLwas adequate as long as what applications were generally doing was simplydisplaying pages to users. However, more complex applications require programsto be able to recognize and process parts of Web pages that have specificsemantic meaning within the application. In some cases, applications requiredata that has a well-defined, fixed format (such as an invoice or otherform). Even if applications don't require such fully regular structures,they often need the ability to identify specific pieces of a page's contents.For example, a document may not have a fixed number of authors, but itis still important to be able to identify the strings of text that correspondto authors' names. In some cases, these "pieces" would correspondto specific fields in records, such as "author". In other cases,they would correspond to specific relationships (e.g., a "citation"link to a related paper).
These are the same structuring requirements that apply to object statein object models; i.e., an object's state must be structured in such away that the object methods can find the parts of the state that they needin order to execute properly. As compared with HTML, whose tags are primarilyconcerned with how the tagged information is to be presented, satisfyingthis structuring requirement involves some form of semantic markup,i.e., the ability to tag items with names that can be used to identifyitems based (at least to some extent) on their semantics.
This section describes a number of developments directed at dealingwith the problems of providing richer data structuring capabilities forWeb data.
Harvest's Summary Object Interchange Format (SOIF) is a syntax for representingand transmitting descriptions of (metadata about) Internet resources suchas files, sites, Web pages, etc., as well as other kinds of structuredobjects (see Internetdraft: CIP Index Object Format for SOIF Objects <http://www.globecom.net/(eng)/ietf/draft/draft-ietf-find-cip-soif-01.shtml>).SOIF is based on a combination of the Internet Anonymous FTP Archives (IAFA)IETF Working Group templates and BibTeX. Each resource descriptionis represented in SOIF as a list of attribute-value pairs (e.g., Company= 'Netscape'). SOIF handles both textual and binary data as values, and,with some minor extensions, multivalued attributes. SOIF also allows bulktransfer of many resource descriptions in a single, efficient stream. ASOIF stream contains one or more SOIF objects, each of which contains thestructured content of a resource description. An example SOIF object mightbe:
@DOCUMENT { http://www.netscape.com:80/ Title{20}: Welcome to Netscape! Last-Modified{29}: Thu, 16 May 1996 11:45:39 GMT }Resource Description Messages(RDM) <http://www.w3.org/TR/NOTE-rdm>, 24 July 1996, by DarrenHardy (Netscape), is a technical specification of Resource DescriptionMessages (RDM). RDM is used in Netscape's Catalog Server. RDM is a mechanismto discover and retrieve metadata about network-accessible resources, knownas Resource Descriptions (RDs). A Resource Description consists of a listof attribute-value pairs (e.g., Author = Darren Hardy, Title = RDM)and is associated with a resource via a URL. Agents can generate RDs automatically(e.g., a WWW robot), or people can write RDs manually (e.g., a librarianor author). Once a repository of Resource Descriptions is assembled, theserver can export it via RDM as a programmatic way for WWW agents to discoverand retrieve the RDs.
RDM uses Harvest's SOIF format to encode the RDs. The data model thatSOIF provides is a flat name space for the attributes, and treats all valuesas blobs. The RDM schema definition language extends the SOIF data modelby providing:
SOIF illustrates a theme that will be repeated in other Web-relatedstructured data representations discussed here: the representation of dataas semantically tagged data items (attribute/value pairs),where the tags or attribute names convey something of the meaning of theassociated data value. A key advantage of an approach based on individualattribute/value pairs is that, unlike a database-like "typed record"approach, it is arbitrarily extensible in a federated environment likethe Web (without a centralized collection of types or schema). Anyone canrecord any attributes they feel are necessary, without going through the"overhead" of defining a new type (and, in particular, possiblyhaving to define it as a subtype of an existing type), and distributingthat type definition throughout a distributed network.
However, while SOIF supports attribute/value pairs, its structuringcapabilities are not sufficiently rich to support the full structuringrequirements of the Web. For example, it lacks support for nested structures,and cannot support the functionality of HTML, let alone extensions to it.It is also not well integrated with more advanced developments in Web datarepresentation, such as XML, RDF, and DOM, described later.
Stanford's Object Exchange Model (OEM) [PGW95, AQMW+96] is a "lightweightobject model" developed to act as a general model capable of representingboth database and Web data structures. A similar model, developed at theUniversity of Pennsylvania, is described in [BDHS96, BDFS97]. OEM was introducedin TSIMMIS (The Stanford-IBM Manager of Multiple Information Sources) asa self-describing way of representing metadata. OEM was later modifiedfor use in the Lore (Lightweight Object Repository) system. OEM existsin two main variants. In the original (TSIMMIS) version, OEM defines aset of labeled nodes. Each node has an object identifier (oid),a label, a type, and a value (the type defines the type of the value).The types include primitive types such as integer, and set. If thetype is set, the value consists of a set of oids of other nodes.This allows aggregate structures to be defined. These structures are shownin the figure below.
original (TSIMMIS) OEM:
+-----+-------+------+-------+| oid | label | type | value | type includes "set"+-----+-------+------+-------++-----+-------+------+-----------------+| oid | label | set | {oid, oid, ...} | +-----+-------+------+-----------------+In the newer (Lore) version of OEM, the structures have been modifiedso that edges are labeled rather than nodes. In this scheme, a complexobject consists of a set of (label,oid) pairs. These effectively representrelationships between the containing object and the target object. Thatis, a given (label,targetoid) pair contained in object sourceobject representsthe relationship
label(sourceobject, targetobject)
This revised structure thus more closely resembles a first order logic(FOL) structuring of data. These structures are shown in the figure below.
new (Lorel) OEM:
atomic object+-----+------+-------+| oid | type | value | +-----+------+-------+complex object+-----+---------+-------------------------------------------+| oid | complex | value = {(label, oid), (label, oid), ...} | +-----+---------+-------------------------------------------+Since individual objects do not have labels in this scheme, additionallabels are introduced so that top-level objects can also have names.
As an example, a simple structure for information on books in a librarymight have the following structure in the TSIMMIS OEM:
+----+---------+------+---------------+| &1 | library | set | {&2, &5, ...} | +----+---------+------+---------------++----+------+------+----------+| &2 | book | set | {&3, &4} | +----+------+------+----------++----+--------+--------+-----+| &3 | author | string | Aho | +----+--------+--------+-----++----+-------+---------+-----------+| &4 | title | string | Compilers | +----+-------+---------+-----------+Linearly, this might be represented as:
<&1, library, set, {&2,&5,...} ><&2, book, set, {&3,&4} ><&3, author, string, Aho ><&4, title, string, Compilers >In the Lorel OEM, the same structure would be:
+----+------+-----------------------------+library: | &1 | set | {(book,&2), (book,&5), ...} | +----+------+-----------------------------+ +----+------+---------------------------+ | &2 | set | {(author,&3), (title,&4)} | +----+------+---------------------------+ +----+--------+-----+ | &3 | string | Aho | +----+--------+-----+ +----+---------+-----------+ | &4 | string | Compilers | +----+---------+-----------+OEM can represent complex graph structures, similar to those that existin the Web. It is a "lightweight" object model in the sense that:
OEM and related models effectively define global models for a federateddatabase system, where the federated components include unstructured orsemistructured data sources such as the Web (unlike the more conventionalstructured database sources usually considered in federated database systems).These models provide a valuable core of ideas for applying database conceptsto Web data. As the examples illustrate, OEM is based on the use of attribute/valuepairs. This is important in allowing the individual components of Web resourcesto be recognized and accessed in a meaningful way by applications. In addition,OEM extends the basic attribute/value pair model by providing each pairwith its own identifier. This is important in allowing complex nested andgraph structures to be defined. It is also potentially important in allowingadditional descriptive information (metadata) to be directly associatedwith the pairs (e.g., to describe an attribute's meaning more fully). However,this latter idea has not directly followed up in the OEM-related papersreviewed.
While these models are intended to represent data in (or extracted from)Web and other resources, and hence constitute a form of metadata, the capabilitiesof these models for representing metadata that might already exist abouta resource, and for representing their own metadata, are somewhat undeveloped.They do not explicitly consider capturing type and schema information whereit exists, or linking that type information to the structures it describes.For example, when OEM is used to capture a database structure, a schemaactually exists for this data, unlike Web resources. It should be possibleto capture both the data and the schema in OEM, and link them together.This is not really followed up in existing OEM work (although it couldbe). Related work has been done on a concept called DataGuides [GW97,NUWC97]. A DataGuide resembles a schema, but is derived dynamically asa summary of the structures that have been encountered, and only approximatelydescribes the structures that may actually be encountered. This is appropriatefor unstructured and semistructured data, but does not fully representthe semantics of an actual schema.
These models as currently implemented are also not well integrated withemerging Web technologies, such as the XML, DOM, and RDF work describedbelow, that are likely to change the basic nature of the Web's representation.The approach taken in work such as OEM has so far assumed that the Webwill continue to be largely unstructured or semistructured, based on HTML,and that data from the Web will need to be extracted into separate OEMstructures (or interpreted as if it had been) in order perform database-likemanipulations on it. On the other hand, the new Web technologies providea higher level, more semantic representational structure, which can startwith the assumption that information authors themselves have support toprovide more semantic structural information. Our work on a Web objectmodel is based on the idea that, with this additional representation support,it makes sense to investigate building more database-like capabilitieswithin the Web infrastructure itself, rather than assuming that almostall of these database capabilities need to be added externally. Since Webstructures are unlikely to become as regular as conventional databases,some of the principles developed by work such as OEM will continue to beimportant (and, in fact, as a model, OEM has many similarities withwork such as RDF described later in this report). However, it seems likelythat these principles will need to be applied in the context of representationssuch as XML and DOM, used directly as the basis of an enhanced Web infrastructure.
The Knowledge InterchangeFormat <http://logic.stanford.edu/kif/kif.html> provides a commonmeans of exchanging knowledge between programs with differing internalknowledge representation techniques. It is human-readable, with declarativesemantics. It can express first-order logic (FOL) sentences, with somesecond-order capabilities. Translators exist to convert various knowledgerepresentation languages to and from KIF. A simple example of KIF in representinginformation about an ontology (from [BBBC+97]) is:
ontology(o_857)ontology_name(o_857,'healthcare')ontology_frame(o_857,f_123)frame(f_123)frame_name(f_123,'encounter_drg')slot(s_345)frame_slot(f_123,s_345)slot_name(s_345,'patient_age')constraint(c_674)slot_constraint(s_345,c_674)constraint_expression(c_674,[[gt,'patient_age',43] [lt,'patient_age',75]]]
The example illustrates that the KIF representation of data is basedon the use of attribute/value pairs; in fact, this is a direct representationof the way this information might be expressed in first-order logic. Thisalso illustrates the fact that a FOL representation necessarily introducesa number of "intermediate" object identifiers (like o_857and f_123), in order to assert the identity of distinct concepts,and to represent relationships among the various parts of the description.This is similar to the way that OEM introduces identifiers for the individualparts of a resource description. The KIF example particularly illustratesthe use of such identifiers in defining namespaces like frames or ontologies,which qualify contained information.
Like OEM, KIF is capable of representing arbitrary graph structures.Moreover, KIF illustrates the importance of identifying parts of a datastructure representation with logical assertions in conveying semanticsbetween applications. Section 3 will describe how this principle servesthe basis of a formal Web object model definition. However, while KIF iswidely used for knowledge interchange, it, like OEM, is not well integratedwith emerging Web infrastructure technologies.
The Extensible Markup Language(XML) <http://www.w3.org/XML/>, is an ongoing effort within the WorldWide Web Consortium (W3C). XML is a data format for structured documentinterchange on the Web. More specifically, XML defines a simple subsetof SGML (the Standard Generalized Markup Language [ISO86]; see also, e.g.,[DeR97]), and is intended to make it easy to use SGML on the Web. XML isextensible because unlike HTML, which defines a fixed set of tags, XMLallows the definition of customized markup languages with application-specifictags, e.g., <AUTHOR> or <QTY-ON-HAND>, forexchanging information in particular application domains such as chemistry,electronics, or general business. Hence, XML is really a metalanguage(a language for describing languages).
Because authors and providers can design their own document types usingXML, browsers can benefit from improved facilities, and applications canuse tailored markup to process data. As a result, XML provides direct supportfor using application-specific tagged data items (attribute/value pairs)in Web resources, as opposed to the current need to use ad hoc encodingsof data items in terms of HTML tags. [KR97] provides a useful overviewof the potential benefits of using XML in Web-related applications.
Although XML could eventually completely replace HTML, XML and HTMLare expected to coexist for some time. In some cases, applications maywish to define entirely separate XML documents for their own processing,and convert the XML to HTML for display purposes. Alternatively, applicationsmay wish to continue using HTML pages as their primary document format,embedding XML within the HTML for application-specific purposes. For example,[Hop97] describes the use of blocks of XML markup enclosed by <XML>and </XML> tags within an HTML document for this purpose.
XML has considerable industry support, e.g., from Netscape, Microsoft,and Sun. For example, Microsoft has built an XML parser into Internet Explorer4.0 (which uses XML for several applications), has made available XML parsersin Java and C++, together with links to other XML tools (see http://www.microsoft.com/xml/),and has indicated that it will use XML in future versions of MicrosoftOffice products. Microsoft has also contributed to a number of proposalsto W3C on the use of XML as a base for various purposes (some of whichwill be discussed in later sections). Netscape has said it will supportXML via the Meta Content Framework (described in Section 2.2) in a futureversion of its Communicator product. Work is also underway on tying XMLto Java in a number of ways. Other commercial vendors are also developingXML-related software tools. In addition, a number of XML tools are availablefor free non-commercial use. A list of some of these tools is availableat the W3C XML Web page identifiedabove.
A number of industry groups have defined SGML Document Type Definitions(DTDs) for their documents (e.g., the U.S. Defense Department, which requiresmuch of its documentation to be submitted according to defined SGML DTDs);in many cases these could either be used with XML directly, or convertedin a straightforward fashion. Work is already underway to define XML-baseddata exchange formats in both the chemical and healthcare communities.Work has also been done on other applications of XML, e.g., an OntologyMarkup Language (OML) <http://wave.eecs.wsu.edu/WAVE/Ontologies/OML/OML-DTD.html>for representing ontologies in XML.
The W3C XML specification has several parts:
A DTD is usually a file (or several files together) which contains aformal definition of a particular type of document. This acts like a databaseschema, and defines what names can be used for elements, where they mayoccur (e.g., <ITEM> might only be meaningful inside <LIST>),and how they all fit together. The DTD lets processors parse a documentand identify where each elements belongs, so that stylesheets, browsers,search engines, and other applications can be used. The linking of resourceswith the DTDs that describe them is similar to the association of a databaserecord with its schema type, and to the association of an object with itstype or class definition.
An XML document may be either valid or well-formed. Avalid XML document is well-formed, and has a DTD. The document beginswith a declaration of its DTD. This may include a pointer to an externaldocument (a local file or the URL of a DTD that can be retrieved over thenetwork) that contains a subset of the required markup declarations (calledthe external subset), and may also include an internal subsetof markup declarations contained directly within the document. The externaland internal subsets, taken together, constitute the complete DTD of thedocument. The DTD effectively defines a grammar which defines a class ofdocuments. Normally, the bulk of the markup declarations appear in theexternal subset, which is referred to by all documents of the same class.If both external and internal subsets are used, the XML processor mustread the internal subset first, then the external subset. This allows theentity and attribute declarations in the internal subset to take precedenceover those in the external subset (thus allowing local variants in documentsof the same class). XML DTDs can also be composed, so that new documenttypes can be created from existing ones.
A well-formed XML document can be used without a DTD, but mustfollow a number of simple rules to ensure that it can be parsed correctly.These rules require, among other things, that:
The general characteristics of XML can be illustrated using an exampleof a document that maintains a list of people's electronic business cards(this example is modified from one in [KR97], and is not necessarily consistentwith the details of the latest XML specification). Each business card containsthe person's first name, last name, company, email address, and Web pageaddress. There is more than one way to represent attribute-value styledata in XML. One approach is to specify the attributes as the "attributes"of XML tags. In this case, the document contains only tags annotated withattribute-value pairs, and there is no content in the document other thanthe tags themselves (which can be parsed and processed by applications).Using this approach, an example document would be:
<!DOCTYPE bCard "http://www.objs.com/schemas/bCard"><bCard><?xml default bCard firstname = "" lastname = "" company = "" email = "" webpage = ""?><bCard firstname = "Frank" lastname = "Manola" company = "Object Services and Consulting" email = "fmanola@objs.com" webpage = "http://www.objs.com/manola.htm"/><bCard firstname = "Craig" lastname = "Thompson" company = "Object Services and Consulting" email = "thompson@objs.com" webpage = "http://www.objs.com/thompson.htm"/></bCard>
The default specification ensures that every tag has the same numberof attribute-value pairs.
An alternative representation uses different tags, rather than XML attributes,to identify the meaning of the content. Using this approach, the same contentwould be represented as:
<bCard><FIRSTNAME>Frank</FIRSTNAME><LASTNAME>Manola</LASTNAME><COMPANY>Object Services and Consulting</COMPANY><EMAIL>fmanola@objs.com</EMAIL><WEBPAGE>http://www.objs.com/manola.htm</WEBPAGE></bCard><bCard><FIRSTNAME> Craig </FIRSTNAME><LASTNAME> Thompson </LASTNAME><COMPANY>Object Services and Consulting</COMPANY><EMAIL> thompson@objs.com </EMAIL><WEBPAGE>http://www.objs.com/thompson.htm</WEBPAGE></bCard>
The paper XML representationof a relational database <http://www.w3.org/XML/RDB.html> usesa relational database as a simple example of how to represent more complexstructured information in XML. A relational database consists of a setof tables, where each table is a set of records. A recordin turn is a set of fields and each field is a pair field-name/field-value.All records in a particular table have the same number of fields with thesame field-names. This description suggests that a database could be representedas a hierarchy of depth four: the database consists of a set of tables,which in turn consist of rows, which in turn consist of fields.The following example, taken from the cited paper, describes a possibleXML representation of a single database with two tables:
<!doctype mydata "http://www.w3.org/mydata"><mydata><authors><author><name>Robert Roberts</name><address>10 Tenth St, Decapolis</address><editor>Ella Ellis</editor><ms type="blob">ftp://docs/rr-10</ms><born>1960/05/26</born></author><author><name>Tom Thomas</name><address>2 Second Av, Duo-Duo</address><editor>Ella Ellis</editor><ms type="blob">ftp://docs/tt-2</ms></author><author><name>Mark Marks</name><address>1 Premier, Maintown</address><editor>Ella Ellis</editor><ms type="blob">ftp://docs/mm-1</ms></author></authors><editors><editor><name>Ella Ellis</name><telephone>7356</telephone></editor></editors></mydata>
The representation is human-readable, but fairly verbose (since XMLin general is verbose). However, it compresses well with standard compressiontools. It is also easy to print the database (or a part of it) with standardXML browsers and a simple style sheet.
The database is modeled with an XML document node and its associatedelement node:
<!doctype name "url">
<name>
table1
table 2
...
table n
</name>
The name is arbitrary. The url is optional, but can beused to point to information about the database. The order of the tablesis also arbitrary, since a relational database defines no ordering on them.Each table of the database is represented by an XML element node with therecords as its children:
<name>
record1
record2
...
recordm
</name>
The name is the name of the table. The order of the records isarbitrary, since the relational data model defines no ordering on them.A row is also represented by an element node, with its fields as children:
<name>
field1
field2
...
fieldm
</name>
The name is the name of the row type (this was not required inthe original relational model, but the current specification allows definitionof row types); the name is required in XML anyway. The order of the fieldsis arbitrary. A field is represented as an element node with a data nodeas its only child:
<name type="t">
d
</name
If d is omitted, it means the value of the fields is the emptystring. The value of t indicates the type of the value (such asstring, number, boolean, date). If the type attribute is omitted, the typecan be assumed to be `string.'
This example illustrates that XML tags can (and will) represent conceptsat multiple levels of abstraction. The example defines a specific four-levelhierarchy, but does not explicitly define the relational model and indicatethe hierarchical relationships among the various relational constructs.In order to do this in a generic way for all relational databases, therewould need to be explicit tags such as <SCHEMA>, <TABLE>,<ROW>, etc., and a specification of how they should be nested.This is metalevel information as far as the XML representation is concerned,and could be specified in the DTD. The definition of models, such as therelational model, for organizing data for specific purposes, is independentof XML, and needs to be done separately. The definition of such models(in some cases using XML as their representation) is discussed in the nextsection.
An XML document consists of text, and is basically a linearization ofa tree structure. At every node in the tree there are several characterstrings. The tree structure and character strings together form the informationcontent of an XML document. Some of the character strings serve to definethe tree structure; others are there to define content. In addition tothe basic tree structure, there are mechanisms to define connections betweenarbitrary nodes in the tree. For example, in the following document thereis a root node with three children, with one of the children containinga link to one of the other children:
<p><q id="x7">The first child of type q</q><q id="x8">The second child of type q</q><q href="#x7">The third child of type q</q></p>
In this case, the third child contains an href attribute whichpoints to the first child, using its id attribute as an identifier.
The XML linking model is described in the XLLdraft <http://www.w3.org/TR/WD-xml-link>. The full hypertext linkingcapabilities of XML are much more powerful than those of HTML, and arebased on more powerful hypertext technology such as described in HyTime[ISO92] <http://www.hytime.org/> and the TextEncoding Initiative (TEI) <http://www.uic.edu/orgs/tei/>. Thecurrent specification supports both conventional URLs, and TEI extendedpointers. The latter provide support for bidirectional and multi-way links,as well as links to a span of text (i.e., a subset of the document) withinthe same or other documents.
XSL <http://www.w3.org/TR/NOTE-XSL>is a submission defining stylesheet capabilities for XML documents. XMLstylesheets enable formatting information to be associated with elementsin a source document to produce formatted output. XML stylesheet capabilitiesare based on a subset of those defined in the ISO standard Document StyleSemantics and Specification Language (DSSSL) [ISO96] used in formattingSGML documents. The formatted output is created by formatting a tree offlow objects. A flow object has a class, which represents a kindof formatting task, together with a set of named characteristics, whichfurther specify the formatting. The association of elements in the sourcedocument tree to flow objects is defined using construction rules.A construction rule contains a pattern to identify specific elementsin the source tree, and an action to specify a resulting subtreeof flow objects. The stylesheet processor recursively processes sourceelements to produce a complete flow object tree which defines how the documentis to be presented.
The XML working group is also currently developing a Namespacefacility <http://www.w3.org/TR/1998/NOTE-xml-names> that willallow Generic Identifiers (tag names) to have a prefix which will makethem unique and will prevent name clashes when developing documents thatmix elements from different schemas. This facility allows a document'sprolog to contain a set of Processing Instructions (an SGML concept) ofthe form:
<?xml:namespace name="some-uri" as="some-abbreviation"?>
for example
<?xml:namespace name="http://www.w3.org/schemas/rdf-schema" as="RDF"?> <?xml:namespace name="http://www.purl.org/DublinCore/schema" as="DC"?>
Elements in the document may then use generic identifiers of the form<RDF:assertions> or <DC:Title>. Those element names would expandto URIs such as http://www.w3.org/schemas/rdf-schema#assertions. This workis still under development, and the details of the final specificationmay differ from those described here.
XML provides basic tagged value support, as well as support for nesting,and enhanced link capabilities. Because the Web community is increasinglytargeting XML as its "next generation Web representation", theWeb object model described in Section 3 uses XML as its basic representationof object state. However, additional concepts must also be defined to applyXML to extended data and metadata structuring requirements, and particularlythe requirements for a Web object model that go beyond a richer state representation.Some of these requirements are illustrated both by the relational databaseexample above, and by the RDF and related efforts described in the nextsection. These efforts generally involve defining data model concepts forrepresenting specific kinds of data (as the relational model does for databasedata), and then using the tagged value structures supported by XML as theirrepresentation. These models support various ways of using identifier concepts(URLs plus other identifier concepts) to provide support for graph structureddata. An additional general requirement, not generally addressed by Web-relatedactivities, is the definition of structured database capabilities (e.g.,an algebra or calculus to serve as the basis for database-like query andview facilities for XML data).
Richer representation techniques for Web information, such as XML, arean important component in making the Web an improved basis for enhancedapplications of all kinds. However, additional structure must also be defined.For example, XML provides support for the representation of data in termsof attribute/value pairs, with user-defined tags. However, this alone willnot provide for easy interchange of information, and interoperability amongcomponents since, using XML, different users could define their own waysof using attribute-value pairs to represent the same (or the same typeof) information. Thus, there is also a need to define additional characteristicsof what to represent using representations such as XML.
A data model defines one level of "what to represent". Forexample, the relational data model defines structuring concepts such asrows and tables, and provides one basic organizational framework for representingdata. The example from the previous section of how to represent relationaldata in XML illustrated how using the relational model imposed additionalstructure on the XML representation. Defining a data model for data representedin XML both suggests specific structuring concepts for using XML to organizedata, and may also involve the specification of certain standard tags orattributes (like <TABLE>) to reflect those concepts. Useof particular data models (represented using techniques such as XML) regularizesthe structures that may be encountered, and potentially simplifies thetask of applications that process those structures.
An additional level of "what to represent" is provided bystandardizing the use of domain-specific attribute/value pairs and documentstructures (e.g., standards for specific kinds of reports or forms). SGMLand XML DTDs constitute one way to specify such standards, and there arealready numerous SGML DTDs in use for this purpose (these could, in mostcases, be easily adapted for use with XML).
An important source of efforts to develop such higher-level model specificationsfor use on the Web has been work on developing representation techniquesfor Web metadata, i.e., data available via the Web that describesor helps interpret either other Web resources or non-Web resources. Thismetadata is used both to facilitate Web searches for relevant data, andto either provide direct access to it (if it is Web-accessible) or at leastindicate its existence and possibly describe how to obtain it. The reasonwhy the development of metadata representations has driven the developmentof higher-level models is that the metadata is intended to support indexing,searching, and other automated processes that require more structure thanmay be present in the data itself. Metadata requirements have also driventhe development of structured representations themselves. For example,the SOIF format described in Section 2.1.1 was developed to represent Webmetadata.
Efforts to develop enhanced metadata capabilities have involved severaltypes of activity (a given effort may bundle more than one of them):
Web data/metadata models defined "on top of" representationssuch as XML are relevant to the development of a Web object model in helpingto further define an adequate basis for representing object state. In addition,these models are also relevant in helping to identify ways to establishrelationships between the object state and the specified pieces of codethat serve as object methods. This is based on the idea that an "object"is basically a piece of state with some attached (or associated) programs(methods). For example, a Smalltalk object consists of a set of state variables(data), together with a pointer (link) to a class object which containsits methods. The link between an object and its class is essentially ametadata link, since the class methods are used to help interpret the data.In the Web environment, the idea is that objects can be constructed byenhancing Web resources with additional metadata that allows the resourcesto be considered as objects in some object model. This concept will bedeveloped further in Section 3, but is mentioned here to further explainthe role that metadata structuring principles will play in the developmentof a Web object model.
The Dublin Core<http://purl.oclc.org/metadata/dublin_core/> is a set of specificmetadata attributes originally developed at the March 1995 Metadata Workshopin Dublin, Ohio. The set has subsequently been modified on the basis oflater Dublin Core Metadata Workshops. The goal of the Dublin Core is todefine a minimal set of descriptive elements that facilitate the descriptionand the automated indexing of document-like networked objects. The Coremetadata set is intended to be suitable for use by resource discovery toolson the Internet, such as the "WebCrawlers" employed by popularWorld Wide Web search engines (e.g., Lycos and Alta Vista). In addition,the core is meant to be sufficiently simple to be understood and used bythe wide range of authors and casual publishers who contribute informationto the Internet. The Dublin Core reflects input from a wide range of communitiesinterested in metadata, including both the Internet and Digital Librarycommunities. The elements of the Dublin Core (as of November 1997) aregiven below. The DublinCore Reference Description <http://purl.org/metadata/dublin_core_elements>contains the current definition.
In addition to enumerating these data elements, the Dublin Workshopreport specified a number of underlying principles that apply to the entirecore metadata set.
These principles illustrate a number of requirements in a general metadatamodel, including:
These same principles are illustrated in a number of the specific metadatamodels described later in this section, such as MCF and RDF.
The WarwickFramework <http://cs-tr.cs.cornell.edu:80/Dienst/UI/2.0/Describe/ncstrl.cornell/TR96-1593>defines a container architecture that builds on the Dublin Core results.It is a mechanism for aggregating distinct packages of metadata,allowing multiple, separately-managed metadata sets to be defined, managed,and associated with the resources they describe. The report also describesproposals for representing Warwick Framework structures using HTML, MIME,SGML, and a distributed object architecture. (See also the overview papersat http://www.dlib.org/dlib/july96/07weibel.htmland http://www.dlib.org/dlib/july96/lagoze/07lagoze.html.)
The Warwick Framework has two fundamental components: packages,which are typed metadata sets, and containers, which are the unitsfor aggregating packages.
A container may be either transient or persistent. In its transientform, it exists as a transport object between and among repositories, clients,and agents. In its persistent form, it exists as a first-class object inthe information infrastructure. That is, it is stored on one or more serversand is accessible from these servers using a globally accessible identifier(URI). A container may also be wrapped within another object (i.e., onethat is a wrapper for both data and metadata). In this case the "wrapper"object will have a URI rather than, or in addition to, the metadata containeritself.
Independent of the implementation, the only operation defined for acontainer is one that returns a sequence of packages in the container.There is no provision in this operation for ordering the members of thissequence and thus no way for a client to assume that one package is moresignificant or "better" than another.
Each package is a typed object; its type may be determined after accessby a client or agent. Packages are of three types:
+--------------------+| container || || +---------------+ || | package | || | (Dublin Core) | || +---------------+ || +---------------+ || | package | || | (MARC Record) | || +---------------+ | +------------------------+| +---------------+ | URI | package || | package |-+------>| (terms and conditions) || | (indirect) | | +------------------------+| +---------------+ |+--------------------+
Figure 1- Metadata container with three packages (one indirect)
Figure 1 illustrates a simple example of a Warwick Framework container.The container in this example contains three logical packages of metadata.The first two, a Dublin Core record and a MARC record, are contained withinthe container as a pair of packages. The third metadata set, which definesthe terms and conditions for access to the content object, is referencedindirectly via a URI in the container (the syntax for terms and conditionsmetadata and administrative metadata is not yet defined).
The mechanisms for associating a Warwick Framework container with acontent object (i.e., a document) depend on the implementation ofthe Framework. The proposed implementations discussed in the cited referenceillustrate some of the options. For example, a simple Warwick Frameworkcontainer may be embedded in a document, as illustrated in the HTML implementationproposal; or an HTML document can include a link to a container storedas a separate file. On the other hand, as illustrated in the distributedobject proposal, a container may be a logical component of a so-calleddigital object, which is a data structure for representing networked objects.
The reverse linkage, which ties a container to a piece of intellectualcontent, is also relevant, since anyone can create descriptive data fora networked resource, without permission or knowledge of the owner or managerof that resource. This metadata is fundamentally different from the metadatathat the owner of a resource chooses to link to or embed with the resource.As a result, an informal distinction is made between two categories ofmetadata containers, which both have the same implementation:
One of the motivations for the development of the Warwick Frameworkwas a recognition that, even if attention is restricted to metadata fordescriptive cataloging (the subject of the Dublin Core), many differentformats for such metadata have been defined (including specialized formsfor particular kinds of data, such as geospatial data), and techniquesmust be defined for organizing the metadata about an object that may appearin these multiple forms.
Another motivation was the recognition that there are many other kindsof metadata besides that used for descriptive cataloging that may needto be recorded and organized. These kinds of metadata include, among others:
The Warwick Framework illustrates a number of very basic structuralrequirements and options that must be supported in representing metadata,and linking it with the data it describes. Like the principles reflectedin the Dublin Core, the Warwick Framework principles are illustrated ina number of the specific metadata models described later in this section,such as the RDF. For example, RDF assertions (see below) correspondclosely to Warwick Framework packages, and the various means provided forassociating RDF assertions with the resources they describe support optionsidentified in the Warwick Framework.
PICS (Platform for Internet ContentSelection) <http://www.w3.org/PICS/> is an infrastructure forassociating labels (metadata) with Internet content. It was originallydesigned to help parents and teachers control what children access on theInternet, but it also facilitates other uses for labels, including codesigning, privacy, and intellectual property rights management. PICS currentlydefines the following recommendations:
In PICS, a rating service is an individual or organization thatprovides content labels for resources on the Internet. The labels it providesare based on a rating system. Each rating service must describeitself using a PICS-defined MIME type application/pics-service.Selection software that relies on ratings from a PICS rating service canfirst load the application/pics-service description. This descriptionallows the software to tailor its user interface to reflect the detailsof a particular rating service.
Each rating service picks a URL as its unique identifier, and includesthis unique identifier in all content labels the service produces. It isintended that the URL, in addition to simply being a unique identifier,also refer to an HTML document which describes both the rating service,but also the rating system used by the service (possibly via a link toa separate document).
A rating system specifies the dimensions used for labeling, thescale of allowable values for each dimension, and a description of thecriteria used in assigning values. For example, the MPAA rates movies inthe U.S. based on a single dimension with allowable values G, PG, PG-13,R, and NC-17. The current PICS specification allows only floating pointvalues.
Each rating system is identified by a URL. This allows multiple servicesto use the same rating system, and refer to it by its identifier. The URLidentifying a rating system can be accessed to obtain a human-readabledescription of the rating system.
A content label, or rating, contains information abouta document. The format of a content label is defined in the Label Formatdocument referenced above, and has three parts:
A new MIME type application/pics-labels is also defined for transmittingone or more content labels.
When an end-user attempts to access a particular URL, a software filterbuilt into the Web client (browser) fetches the document. The client alsoaccesses the document's content label(s) based on rating systems that theclient has been told to pay attention to. The client then compares thecontent label to the rating-system-specified values that the client hasbeen told to base access decisions on, and either allows or denies accessto the document.
Content labels may be:
The following application/pics-service document (taken from the PICSspecification) describes a simple rating service.
((PICS-version 1.1) (rating-system "http://www.gcf.org/ratings") (rating-service "http://www.gcf.org/v1.0/") (icon "icons/gcf.gif") (name "The Good Clean Fun Rating System") (description "Everything you ever wanted to know about soap,cleaners, and related products") (category (transmit-as "suds") (name "Soapsuds Index") (min 0.0) (max 1.0)) (category (transmit-as "density") (name "suds density") (label (name "none") (value 0) (icon "icons/none.gif")) (label (name "lots") (value 1) (icon "icons/lots.gif"))) (category (transmit-as "subject") (name "document subject") (multivalue true) (unordered true) (label (name "soap") (value 0)) (label (name "water") (value 1)) (label (name "soapdish") (value 2)) (label-only)) (category) (transmit-as "color") (name "picture color") (integer) (category (transmit-as "hue") (label (name "blue") (value 0)) (label (name "red") (value 1)) (label (name "green") (value 2))) (category (transmit-as "intensity") (min 0) (max 255))))
There are four top-level categories in this rating system. Each categoryhas a short transmission name to be used in labels (e.g., "suds");some also have longer names that are more easily understood (e.g., "SoapsudsIndex"). The "Soapsuds Index" category rates soapsuds ona scale between 0.0 and 1.0 inclusive. The "suds density" categorycan have ratings from negative to positive infinity, but there are twovalues that have names and icons associated with them. The name "none"is the same as 0, and "lots" is the same as 1. The "documentsubject" category only allows the values 0, 1, and 2, but a singledocument can have any combination of these values. The "picture color"category has two sub-categories.
A label list is used to transmit a set of PICS labels. The followingis a label list for two documents rated using the above rating system.
(PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels on "1994.11.05T08:15-0500" until "1995.12.31T23:59-0000" for "http://www.w3.org/PICS/Overview.html" ratings (suds 0.5 density 0 color/hue 1) for "http://www.w3.org/PICS/Underview.html" by "Jane Doe" ratings (subject 2 density 1 color/hue 1))
PICS-NG (Next Generation) was a W3C effort based on the observationthat the PICS infrastructure could be generalized to support arbitraryWeb metadata, with PICS categories serving as metadata attributes, havingmeanings defined by the rating system. The W3C paper Catalogs:Resource Description and Discovery <http://www.w3.org/pub/WWW/Search/catalogs.html>also observes that the structure of a PICS label is similar to:
The PICS-NG effort defined a Metadata Object Model, and its encodingsin XML and as S-expressions, in the note PICS-NGMetadata Model and Label Syntax <http://www.w3.org/TR/NOTE-pics-ng-metadata>.This model includes a number of extensions to the original PICS representationscheme, in order to support more general forms of metadata. These extensionsinclude such things as:
Other papers related to this effort include:
The PICS-NG effort has been merged with other work to become W3C's ResourceDescription Framework activity (see Section 2.2.6).
PICS illustrates a number of important ideas in data modeling and metadatarepresentation. One such idea is the definition of specific requireddata items (e.g., category, label) having predefinedmeanings in the model. Such specifications are important in supportinginteroperability among applications that use PICS ratings. PICS also illustratesthe use of metalevel pointers. The URLs that identify rating servicesand rating systems in PICS point to information that describes PICS metadata(i.e., to metametadata). These illustrate the idea that a given piece ofdata on the Web, no matter what its intended purpose (e.g., whether itis intended to represent data or metadata), can itself point to (or berelated in some other way to) data that can be used to help interpret it.Finally, PICS illustrates the use of a metalevel (or reflective)architecture. PICS requires that ordinary requests for data on theWeb be interrupted or intercepted, so that rating information about therequested resource can be retrieved, and a decision made about whetherto return the requested data or not. This same basic idea can be used toenhance individual requests with other types of additional processing,often transparently to users. For example, such processing could be usedto bracket a collection of individual requests to form a database-liketransaction, by adding interactions with a transaction processor to theserequests. Examples of such processing are described in [CM93, Man93, SW96].These same ideas are the basis for current OBJS work on an IntermediaryArchitecture <http://www.objs.com/workshops/ws9801/papers/paper103.html>for the Web.
As illustrated by the existence of a PICS-NG effort, PICS itself requiresextensions to deal with more general metadata requirements. Some of theseare described further in the discussion of the Resource Description Framework(Section 2.2.6). In addition, in order to provide a complete Web objectmodel, PICS and similar ideas must be augmented with an API providing applicationswith easy access to the state, and with mechanisms to link code to thestate represented using models such as PICS. These aspects will be discussedin subsequent sections.
XML-Data <http://www.w3.org/TR/1998/NOTE-XML-data/>is a submission to W3C by Microsoft, ArborText, DataChannel, and INSO.XML-Data defines an XML vocabulary for schemas, that is, for definingand documenting object classes. It can be used either for classes whichare strictly syntactic (for example, XML), or which indicate concepts andrelations among concepts (as used in relational databases, knowledge representationgraphs, and RDF). The former are called "syntactic schemas;"the latter "conceptual schemas."
For example, an XML document might contain a "book" elementwhich lexically contains an "author" element and a "title"element. An XML-Data schema can describe such syntax. However, in anothercontext, it may simply be necessary to represent more abstractly that bookshave titles and authors, irrespective of any syntax. XML-Data schemas canalso describe such conceptual relationships. Further, the information aboutbooks, titles and authors might be stored in a relational database, inwhich case XML-Data schemas can describe the database row types and keyrelationships.
One immediate implication of the ideas in XML-Data is that, using XML-Data,XML document types can be described using XML itself, rather than DTD syntax.Another is that XML-Data schemas provide a common vocabulary for ideaswhich overlap between syntactic, database and conceptual schemas. All featurescan be used together as appropriate.
Schemas in XML-Data are composed principally of declarations for:
The following simple example taken from the XML-Data submission showssome data about books and authors, and the XML-Data schema which describesit (note the use of the XML Namespace facility, described in Section 2.1.4,for qualifying names).
Some data:
<?xml:namespace name="http://company.com/schemas/books/" as="bk"/><?xml:namespace name="http://www.ecom.org/schemas/dc/" as="ecom" ?><bk:booksAndAuthors> <Person> <name>Henry Ford</name> <birthday>1863</birthday> </Person> <Person> <name>Harvey S. Firestone</name> </Person> <Person> <name>Samuel Crowther</name> </Person> <Book> <author>Henry Ford</author> <author>Samuel Crowther</author> <title>My Life and Work</title> </Book> <Book> <author>Harvey S. Firestone</author> <author>Samuel Crowther</author> <title>Men and Rubber</title> <ecom:price>23.95</ecom:price> </Book></bk:booksAndAuthors>
The schema for http://company.com/schemas/books:
<?xml:namespace name="urn:uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882/" as="s"/?><?xml:namespace href="http://www.ecom.org/schemas/ecom/" as="ecom" ?><s:schema> <elementType id="name"> <string/> </elementType> <elementType id="birthday"> <string/> <dataType dt="date.ISO8601"/> </elementType> <elementType id="Person"> <element type="#name" id="p1"/> <element type="#birthday" occurs="OPTIONAL"> <min>1700-01-01</min><max>2100-01-01</max> </element> <key id="k1"><keyPart href="#p1" /></key> </elementType> <elementType id="author"> <string/> <domain type="#Book"/> <foreignKey range="#Person" key="#k1"/> </elementType> <elementType id="writtenWork"> <element type="#author" occurs="ONEORMORE"/> </elementType> <elementType id="Book" > <genus type="#writtenWork"/> <superType href=" http://www.ecom.org/schemas/ecom/commercialItem"/> <superType href=" http://www.ecom.org/schemas/ecom/inventoryItem"/> <group groupOrder="SEQ" occurs="OPTIONAL"> <element type="#preface"/> <element type="#introduction"/> </group> <element href="http://www.ecom.org/schemas/ecom/price"/> <element href="ecom:quantityOnHand"/> </elementType> <elementTypeEquivalent id="livre" type="#Book"/> <elementTypeEquivalent id="auteur" type="#author"/></s:schema>
While this example does not illustrate all of the capabilities of XML-Data,it does illustrate the capabilities of declaring such things as:
The submissionshould be referenced for further details and additional examples.
XML-Data is another example of a higher-level model built using XMLas its representation. It is not yet clear how the overlap in metadatacapabilities between such representations as DTDs, RDF, and XML-Data willwork out. The XML-Data approach may prove to be better than DTDs in supportingsome types of processing, such as database-like operations, since it makesno distinctions between data and metadata representations. Like the otherdata models described in this section, XML-Data is not sufficient to forma complete Web object model. In particular, it requires integration withan API facility and a mechanism to access associated code.
Netscape's Meta ContentFramework (MCF) <http://www.w3.org/TR/NOTE-MCF-XML/> [GB97] isa proposal for a metadata model based on the increasing need for machine-readabledescriptions of distributed information. MCF is based on the followingprinciples:
The latter point is particularly important. If all applications savetheir data in XML format, this would be somewhat more open than the useof proprietary formats, since any application could access the resultingdocuments. However, in order for applications to meaningfully processthose documents, it would be necessary for the applications to recognizethe various labels and structures used in those documents, and their associatedsemantics. Agreements on data models and vocabularies allow this sort ofmutual recognition of labels and structure among applications, thus supportinginteroperability.
MCF is essentially a structure description language. The basic informationstructure used is the Directed Labeled Graph (DLG). An MCF database isa set of DLGs, consisting of:
Nodes represent things like web pages, images, subject categories, andsites. The labels are nodes that correspond to properties such as sizeor lastRevisionDate used to describe web pages, subject categories,etc., and also to define relations such as hyperlinks, authorship, or parenthood,between these things.
Each label/property type, such as pageSize, is a node (but notall nodes are property types). Since labels are nodes, they can participatein relationships that, e.g., define its semantics. For example, a pageSizenode could have properties that specify its domain (e.g., Document),its range (sizeInBytes), that a Document has only one pageSize,and that provide human-readable documentation of the intended semantics.
An MCF node can be either a primitive data type or a "Unit".The primitive data types are the same as the Java primitive types. In addition,a DATE type should be supported by the low-level MCF machinery. The conceptof a "Unit" corresponds loosely to the Java concept of "Object".
MCF defines a small set of units with predefined semantics in orderto "bootstrap" the type system. These include, among others:
MCF recognizes that, for purposes of interoperability, it would be goodto standardize the vocabulary for commonly-used terms. [GB97] proposessome items for this vocabulary (largely derived from existing standardssuch as the Dublin Core) for describing Web content. [GB97] also definesan XML-based syntax for representing MCF. This essentially defines a typesystem for XML.
Like PICS, MCF illustrates a number of important ideas in data modelingand metadata representation. For example, MCF illustrates both the useof specific required data items having predefined meanings in the model,and metalevel pointers. Unlike PICS, MCF represents a data model that canbe used for more general purposes than content labeling. For example, itincludes a type hierarchy, a richer set of base types, and other aspectsof a full data model. In addition to required data items representing aspectsof the model structure, the MCF reference identifies a list of suggestionsfor standard application-specific item names borrowed from the Dublin Coreand elsewhere. MCF "units" are similar to the individual elementsof the OEM model. Many MCF concepts have been incorporated into W3C's RDF(described in the next section). However, as noted in connection with othermodels in this section, these concepts must be combined with an API anda mechanism for integrating behavior to provide full object model support.
The World Wide Web Consortium's ResourceDescription Framework (RDF) effort <http://www.w3.org/Metadata/RDF/>is currently developing a mechanism designed for exchanging machine-understandablemetadata describing Web resources. This type of metadata can be used, e.g.:
The work combines extensions of the PICS technology to support moregeneral metadata requirements with work on metadata models such as Netscape'sMeta Content Framework (MCF) and Microsoft's WebCollections [Hop97]. The currentRDF draft specification <http://www.w3.org/TR/WD-rdf-syntax/>defines both a data model for representing RDF metadata, and an XML-basedsyntax for expressing and transporting the metadata.
The basis of RDF is a model for representing named propertiesand their values. These properties serve both to represent attributes ofresources (and in this sense correspond to attribute/value pairs) and torepresent relationships between resources. The RDF data model is asyntax-independent way of representing RDF statements.
The core RDF data model is defined in terms of:
(thus resembling MCF).
In this data model both the resources being described and the valuesdescribing them are nodes in a directed labeled graph (values maythemselves be resources). The arcs connecting pairs of nodes correspondto the names of the property types. This is represented pictorially as:
[resource R] ---propertyType P---> [value V]
and can be read "V is the value of the property P for resourceR", or left-to-right; "R has property P with value V". Forexample the statement "John Smith is the Author of the Web page "http://www.bar.com/some.doc"would be represented as:
[http://www.bar.com/some.doc] ---author---> "John Smith"
where the notation [URI] denotes the instance of the resource identifiedby URI and "..." denotes a simple Unicode string.
According to the above definition, the property "author",i.e. the arc labeled "author" plus its source and target nodesis the triple (3-tuple):
{author, [http://www.bar.com/some.doc], "John Smith"}where "author" denotes a node used for labeling this arc.The triple composed of a resource, a property type, and a value is an RDF statement.
A collection of these triples with the same second item is called anassertions. Assertions are particularly useful when describing anumber of properties of the same resource. Assertions are diagramed asfollows:
[resource R]-+---property P1----> [value Vp1] | +---property P2----> [value Vp2]
An RDF assertions can be a resource itself and can thereforebe described by properties; that is, an assertions can itself beused as the source node of an arc. The name assertions is suggestive ofthe fact that the properties specified in it are effectively (logical)assertions about the resource being described. This establishes a relationshipbetween RDF and a logic-based interpretation of the data structure whichwill be further developed in Section 3.
Assertions may be associated with the resource they describe in oneof four ways:
All resources will not support all association methods (e.g., many resourcetypes will not support embedding).
The set of properties in a given assertions, as well as any characteristicsor restrictions of the property values themselves, are defined by one ormore schemas. Schemas are identified by a URL. An assertionsmay contain properties from more than one schema. RDF uses the XML namespacemechanism to associate the schema with the properties in the assertions.The schema URL may be treated merely as an identifier, or it may referto a machine-readable description of the schema. By definition, an applicationthat understands a particular schema used by an assertions understandsthe semantics of each of the contained properties. An application thathas no knowledge of a particular schema will minimally be able to parsethe assertions into the property and property value components, and willbe able to transport the assertions intact (e.g., to a cache or to anotherapplication).
A human- or machine-readable description of an RDF schema may be accessedthrough content negotiation by dereferencing the schema URL. If the schemais machine-readable, it may be possible for an application to dynamicallylearn some of the semantics of the properties named in the schema.
An RDF statement can itself be the target node of an arc (i.e. the valueof some other property) or the source node of an arc (i.e. it can haveproperties). In these cases, the original property (i.e., the statement)must be reified; that is, converted into nodes and arcs. RDF definesa reification mechanism for doing this. Reified properties are drawnas a single node with several arcs emanating from it representing the resource,property name, and value:
[property P1]-+---PropName---> ["name"] | +---PropObj----> [resource R] | +---PropValue--> [value Vp1]
This allows RDF to be used to make statements about other statements;for example, the statement "Joe believes that the document 'The Originof Species' was authored by Charles Darwin" would be diagramed as:
[Joe]--believes-->[stmnt1]+--InstanceOf-> RDF:Property | +--PropName->"author" | +--PropObj->[http://loc.gov/Books/Species] | +--PropValue->"Charles Darwin"
To help in reifying properties, RDF defines the InstanceOf relation(property) to provide primitive typing, as shown in the example.
To reify a property, all that is done is to add to the data model anadditional node (with a generated label) and the three triples with firstitems (or arcs with labels) using the predefined names RDF:PropName,RDF:PropObj, and RDF:PropValue respectively, second itemthe generated node label, and third item the corresponding property type,resource node, and value node respectively. In the above example, the threeadded triples would be:
{PropName, stmnt1, "author"} {PropObj, stmnt1, [http://loc.gov/Books/Species]} {PropValue, stmnt1, "Charles Darwin"}(The use of the "RDF:" prefix in names illustratesthe use of the XML namespace mechanism to qualify names to indicate theschema in which they are defined.)
Frequently it is necessary to create a collection of nodes; e.g. tostate that a property has multiple values. RDF defines three kindsof collections: ordered lists of nodes, called sequences, unorderedlists of nodes, called bags, and lists that represent alternativesfor the (single) value of a property, called alternatives. To createcollections of nodes, a new node is created that is an RDF:InstanceOfone of the three node types RDF:Seq, RDF:Bag, or RDF:Alternatives.The remaining arcs from that new node point to each of the members of thecollection and are uniquely labeled using the elements from Ord.For the RDF:Alternatives, there must be at least one member whosearc label is RDF:1, and that is the default value for the Alternativesnode.
The RDF data model provides an abstract, conceptual framework for definingand using metadata. A concrete syntax is also needed for the purpose ofauthoring and exchanging this metadata. The syntax does not add to themodel, and APIs could be provided to manipulate RDF metadata without referenceto a concrete syntax. RDF uses XML encoding as its syntax. However, RDFdoes not require an XML DTD for the contents of assertion blocks (and RDFschemas are not required to be XML DTDs). In this respect, RDF requiresat most that its XML representations be well-formed.
RDF defines several XML elements for its XML encoding. The RDF:serializationelement is a simple wrapper that marks the boundaries in an XML document,where the content is explicitly intended to be mappable into an RDF datamodel instance. RDF:assertions and RDF:resource containthe remaining elements that instantiate properties in the model instance.Each XML element E contained by an RDF:assertions or an RDF:resourceresults in the creation of a property (a triple that is an element of theformal set T defined earlier).
With these basic principles defined, directed graph models of arbitrarycomplexity can be constructed and exchanged. A simple example would be"John Smith is the Author of the document whose URL is http://www.bar.com/some.doc"(all these examples are taken from the RDF paper cited above, but updatedto use more recent XML namespace syntax). This assertion can be modeledwith the directed graph:
[http://www.bar.com/some.doc] ---bib:author---> "John Smith"
(This report uses a notation where Nodes are represented by items insquare brackets, arcs are represented as arrows, and strings are representedby quoted items.) This small graph can be exchanged in the serializationsyntax as:
<?xml:namespace name="http://docs.r.us.com/bibliography-info" as="bib"?> <?xml:namespace name="http://www.w3.org/schemas/rdf-schema" as="RDF"?> <RDF:serialization> <RDF:assertions href="http://www.bar.com/some.doc"> <bib:author>John Smith</bib:author> </RDF:assertions> </RDF:serialization>
This example illustrates how the resource, property name, and valueare translated into XML.
A more elaborate model could be created in order to say additional thingsabout John Smith, such as his contact information, as in the model:
[http://www.bar.com/some.doc] | bib:author | V[John Smith]-+---bib:name----> "John Smith" | +---bib:email----> "john@smith.com" | +---bib:phone----> "+1 (555) 123-4567"
which could be exchanged using the XML serialization representation:
<?xml:namespace name="http://docs.r.us.com/bibliography-info" as="bib"?> <?xml:namespace name="http://www.w3.org/schemas/rdf-schema" as="RDF"?> <RDF:serialization> <RDF:assertions href="http://www.bar.com/some.doc"> <bib:author> <RDF:resource> <bib:name>John Smith</bib:name> <bib:email>john@smith.com</bib:email> <bib:phone>+1 (555) 123-4567</bib:phone> </RDF:resource> </bib:author> </RDF:assertions> </RDF:serialization>
The serialization above is equivalent to this second serialization:
<?xml:namespace name="http://docs.r.us.com/bibliography-info" as="bib"?> <?xml:namespace name="http://www.w3.org/schemas/rdf-schema" as="RDF"?> <RDF:serialization> <RDF:assertions href="http://www.bar.com/some.doc"> <bib:author href="#John_Smith"/> </RDF:assertions> </RDF:serialization><RDF:resource id="John_Smith"> <bib:name>John Smith</bib:name> <bib:email>john@smith.com</bib:email> <bib:phone>+1 (555) 123-4567</bib:phone> </RDF:resource>
In these representations, the RDF:resource element createsan in-line resource. Typically such a resource will be a surrogate, orproxy, for some other real resource that does not have a recognizable URI.The id= attribute in the second representation provides a namefor the resource element so that the resource may be referred to elsewhere.
As an example of making a statement about a statement, consider thecase of computing a digital signature on an RDF assertion. (It is assumedthat the signature is computed over a concrete XML representation of theassertion rather than over an internal representation. The figure belowshows a box containing a small graph. This is a convention to indicatethat the XML content whose ID is foo is a concrete representation of thegraph it contains.) What is to be specified in the model is expressed bythe pair of graphs below - that there is an XML encoding of some assertion,and that there is some other XML content that is a digital signature overthat encoding.
+---------------------------------------------------------------+| ID=foo || || [http://www.bar.com/some.doc] ---DC:creator---> "John Smith" || |+---------------------------------------------------------------+[foo]------DSIG:Signature------>"AKGJOERGHJWEJ348GH4GHEIGH4ROI4"
The details could be expressed in the model below:
"AKGJOERGHJWEJ348GH4GHEIGH4ROI4"<--RDF:PropValue----+ | [DSIG:Signature]<----RDF:PropName-----+ | +--RDF:InstanceOf-->[RDF:Property]<--RDF:InstanceOf--+ | | | | [foo]<----------------RDF:PropObj-----------------[prop-001] | | +---------------------------------------------+ | | +-----------------------------+ | | | | RDF:PropObj RDF:PropName RDF:PropValue | | | V V V[http://www.bar.com/some.doc] ---DC:creator---> "John Smith"
These models could also be expressed as:
<?xml:namespace name="http://purl.org/DublinCore/RDFschema" as="DC"?> <?xml:namespace name="http://www.w3.org/schemas/rdf-schema" as="RDF"?><?xml:namespace name="http://www.w3.org/schemas/DSig-schema" as="DSIG"?><RDF:serialization> <RDF:assertions href="http://www.bar.com/some.doc" id="foo"> <DC:Creator>John Smith</DC:Creator> </RDF:assertions> <RDF:assertions href="#foo"> <DSIG:Signature>AKGJOERGHJWEJ348GH4HGEIGH4ROI4</DSIG:Signature> </RDF:assertions></RDF:serialization>
(Note that node labels such as "RDF:Property" are shorthandfor a full URI such as "http://www.w3.org/schemas/rdf-schema#Property").
The RDF data model intrinsically only supports binary relations. However,higher arity relations can also be represented, using just binary relations.As an example, consider the subject of one of John Smith's recent articles- library science. The Dewey Decimal Code for library science could beused to categorize that article. While the numeric code is the true Deweyvalue,