10 February 1998
A number of ongoing activities are attempting to merge aspects of object models with those of the World Wide Web. This paper describes a number of these activities, with particular emphasis on those which focus on providing enhanced facilities for representing metadata for describing Web (and other) resources. The intent of this paper is to:
The use of objects in such architectures reflects the fact that advanced software development increasingly involves the use of object technology. This includes the use of object-oriented programming languages, class libraries and application development frameworks, application integration technology such as Microsoft's OLE, as well as distributed object middleware such as CORBA. It also involves the use of object analysis and design methodologies and associated tools.
This use of object technology is driven by a number of factors, including:
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 the coordination of existing software that supports key internal processes and human activities. Mechanisms provided by object technology can help encapsulate 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 being included in software such as DBMSs (including relational DBMSs) and other middleware, and client/server development environments. Due to this factor, organizations may be influenced to begin adopting object technology before they would ordinarily consider doing so.
At the same time, the Internet is becoming an increasingly important factor in planning for enterprise distributed computing environments. For example, companies are providing information via World Wide Web pages, as well as customer access via the Internet to such enterprise computing services as on-line ordering or order/service tracking facilities. Companies are also using Internet technology to create private Intranets, providing access to enterprise data (and, potentially, services) from throughout the enterprise in a way that is convenient and avoids proprietary network technology. Following this trend, software vendors are developing software to allow Web browsers to act as user interfaces to enterprise computing systems, 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 enterprise computing. For example, Web browser software is widely available for most client platforms, and is cheaper than most alternative client applications. Web pages generally work reasonably well with a variety of browsers, and maintenance is simpler since the browser and associated software can reduce the amount of distributed software to be managed. In addition, the Web provides a representation for information which
OMG's Object Management Architecture (OMA) is an example of a distributed object architecture intended to support distributed enterprise computing applications. The OMA includes the following components:
The ORB in the OMA is defined by the CORBA specifications. An ORB does not require that the objects it supports be implemented in an object-oriented programming language. The CORBA architecture defines interfaces for connecting code and data to form object implementations, with interfaces defined by IDL, that are managed by the ORB and its supporting object services. It is this flexibility that enables ORBs to be used in connecting legacy systems and data together as components in enterprise computing architectures.
A distributed enterprise object system must provide functionality beyond that of simply delivering messages between objects. OMG's Object Services have been defined to address some of these requirements. Object Services provide the next level of structure above the basic object messaging support provided 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:
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 nature of the Web. Providing these capabilities involves addressing not only the provision of higher level services and facilities for the Web, but also the suitability of the basic data structuring capabilities provided by the 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 are being investigated. However, the ability to define and apply powerful generic services in the Web, and the ability to generally use the Web to support complex applications, depends crucially on the ability of the Web's underlying data structure to support these complex applications and services.
A more fundamental direction of efforts to address HTML limitations has been attempts to integrate aspects of object technology with the basic infrastructure of the Web. There are a number of reasons for the interest in integrating Web and object 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 representations and extensibility, and provides metalevel concepts for describing and integrating them.
The intent of this paper is to describe how a number of (in some respects) separate "threads" of Web-related development can be combined to form the basis of a Web object model to address these requirements. This combination is based on the observation that the fundamental components of any object model are:
In the following sections, this paper will:
The Introduction specifically noted that what is needed to progress toward a Web object model is:
Several of the sections describe ongoing activities of the World Wide Web Consortium (W3C), particularly:
These are the same structuring requirements that apply to object state in object models; i.e., an object's state must be structured in such a way that the object methods can find the parts of the state that they need in order to execute properly. As compared with HTML, whose tags are primarily concerned with how the tagged information is to be presented, satisfying this structuring requirement involves some form of semantic markup, i.e., the ability to tag items with names that can be used to identify items based (at least to some extent) on their semantics.
This section describes a number of developments directed at dealing with the problems of providing richer data structuring capabilities for Web data.
@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 Darren Hardy (Netscape),
is a technical specification of Resource Description Messages (RDM). RDM
is used in Netscape's Catalog Server. RDM is a mechanism to discover and
retrieve metadata about network-accessible resources, known as Resource
Descriptions (RDs). A Resource Description consists of a list of 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 librarian or author).
Once a repository of Resource Descriptions is assembled, the server can
export it via RDM as a programmatic way for WWW agents to discover and
retrieve the RDs.
RDM uses Harvest's SOIF format to encode the RDs. The data model that SOIF provides is a flat name space for the attributes, and treats all values as blobs. The RDM schema definition language extends the SOIF data model by providing:
However, while SOIF supports attribute/value pairs, its structuring capabilities are not sufficiently rich to support the full structuring requirements 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 data representation, such as XML, RDF, and DOM, described later.
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 modified so
that edges are labeled rather than nodes. In this scheme, a complex
object consists of a set of (label,oid) pairs. These effectively represent
relationships between the containing object and the target object. That
is, a given (label,targetoid) pair contained in object sourceobject represents
the 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, additional
labels are introduced so that top-level objects can also have names.
As an example, a simple structure for information on books in a library might 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 exist
in the Web. It is a "lightweight" object model in the sense that:
While these models are intended to represent data in (or extracted from) Web and other resources, and hence constitute a form of metadata, the capabilities of these models for representing metadata that might already exist about a resource, and for representing their own metadata, are somewhat undeveloped. They do not explicitly consider capturing type and schema information where it exists, or linking that type information to the structures it describes. For example, when OEM is used to capture a database structure, a schema actually exists for this data, unlike Web resources. It should be possible to 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 could be). Related work has been done on a concept called DataGuides [GW97, NUWC97]. A DataGuide resembles a schema, but is derived dynamically as a summary of the structures that have been encountered, and only approximately describes the structures that may actually be encountered. This is appropriate for unstructured and semistructured data, but does not fully represent the semantics of an actual schema.
These models as currently implemented are also not well integrated with emerging Web technologies, such as the XML, DOM, and RDF work described below, 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 Web will continue to be largely unstructured or semistructured, based on HTML, and that data from the Web will need to be extracted into separate OEM structures (or interpreted as if it had been) in order perform database-like manipulations on it. On the other hand, the new Web technologies provide a higher level, more semantic representational structure, which can start with the assumption that information authors themselves have support to provide more semantic structural information. Our work on a Web object model is based on the idea that, with this additional representation support, it makes sense to investigate building more database-like capabilities within the Web infrastructure itself, rather than assuming that almost all of these database capabilities need to be added externally. Since Web structures are unlikely to become as regular as conventional databases, some of the principles developed by work such as OEM will continue to be important (and, in fact, as a model, OEM has many similarities with work such as RDF described later in this report). However, it seems likely that these principles will need to be applied in the context of representations such as XML and DOM, used directly as the basis of an enhanced Web infrastructure.
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 based on the use of attribute/value pairs; in fact, this is a direct representation of the way this information might be expressed in first-order logic. This also illustrates the fact that a FOL representation necessarily introduces a number of "intermediate" object identifiers (like o_857 and 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 individual parts of a resource description. The KIF example particularly illustrates the 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 data structure representation with logical assertions in conveying semantics between applications. Section 3 will describe how this principle serves the basis of a formal Web object model definition. However, while KIF is widely used for knowledge interchange, it, like OEM, is not well integrated with emerging Web infrastructure technologies.
Because authors and providers can design their own document types using XML, browsers can benefit from improved facilities, and applications can use tailored markup to process data. As a result, XML provides direct support for using application-specific tagged data items (attribute/value pairs) in Web resources, as opposed to the current need to use ad hoc encodings of data items in terms of HTML tags. [KR97] provides a useful overview of the potential benefits of using XML in Web-related applications.
Although XML could eventually completely replace HTML, XML and HTML are expected to coexist for some time. In some cases, applications may wish to define entirely separate XML documents for their own processing, and convert the XML to HTML for display purposes. Alternatively, applications may 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 Explorer 4.0 (which uses XML for several applications), has made available XML parsers in 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 Microsoft Office products. Microsoft has also contributed to a number of proposals to W3C on the use of XML as a base for various purposes (some of which will be discussed in later sections). Netscape has said it will support XML via the Meta Content Framework (described in Section 2.2) in a future version of its Communicator product. Work is also underway on tying XML to Java in a number of ways. Other commercial vendors are also developing XML-related software tools. In addition, a number of XML tools are available for free non-commercial use. A list of some of these tools is available at the W3C XML Web page identified above.
A number of industry groups have defined SGML Document Type Definitions (DTDs) for their documents (e.g., the U.S. Defense Department, which requires much of its documentation to be submitted according to defined SGML DTDs); in many cases these could either be used with XML directly, or converted in a straightforward fashion. Work is already underway to define XML-based data exchange formats in both the chemical and healthcare communities. Work has also been done on other applications of XML, e.g., an Ontology Markup 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:
An XML document may be either valid or well-formed. A valid XML document is well-formed, and has a DTD. The document begins with a declaration of its DTD. This may include a pointer to an external document (a local file or the URL of a DTD that can be retrieved over the network) that contains a subset of the required markup declarations (called the external subset), and may also include an internal subset of markup declarations contained directly within the document. The external and internal subsets, taken together, constitute the complete DTD of the document. The DTD effectively defines a grammar which defines a class of documents. Normally, the bulk of the markup declarations appear in the external subset, which is referred to by all documents of the same class. If both external and internal subsets are used, the XML processor must read the internal subset first, then the external subset. This allows the entity and attribute declarations in the internal subset to take precedence over those in the external subset (thus allowing local variants in documents of the same class). XML DTDs can also be composed, so that new document types can be created from existing ones.
A well-formed XML document can be used without a DTD, but must follow a number of simple rules to ensure that it can be parsed correctly. These rules require, among other things, that:
<!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 number of 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 content would 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 representation of a relational database <http://www.w3.org/XML/RDB.html> uses a relational database as a simple example of how to represent more complex structured information in XML. A relational database consists of a set of tables, where each table is a set of records. A record in 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 the same field-names. This description suggests that a database could be represented as 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 possible XML 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 XML in general is verbose). However, it compresses well with standard compression tools. It is also easy to print the database (or a part of it) with standard XML browsers and a simple style sheet.
The database is modeled with an XML document node and its associated element node:
<!doctype name "url">The name is arbitrary. The url is optional, but can be used to point to information about the database. The order of the tables is also arbitrary, since a relational database defines no ordering on them. Each table of the database is represented by an XML element node with the records as its children:
<name>
table1
table 2
...
table n
</name>
<name>The name is the name of the table. The order of the records is arbitrary, since the relational data model defines no ordering on them. A row is also represented by an element node, with its fields as children:
record1
record2
...
recordm
</name>
<name>The name is the name of the row type (this was not required in the original relational model, but the current specification allows definition of row types); the name is required in XML anyway. The order of the fields is arbitrary. A field is represented as an element node with a data node as its only child:
field1
field2
...
fieldm
</name>
<name type="t">If d is omitted, it means the value of the fields is the empty string. The value of t indicates the type of the value (such as string, number, boolean, date). If the type attribute is omitted, the type can be assumed to be `string.'
d
</name
This example illustrates that XML tags can (and will) represent concepts at multiple levels of abstraction. The example defines a specific four-level hierarchy, but does not explicitly define the relational model and indicate the hierarchical relationships among the various relational constructs. In order to do this in a generic way for all relational databases, there would 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 the relational model, for organizing data for specific purposes, is independent of XML, and needs to be done separately. The definition of such models (in some cases using XML as their representation) is discussed in the next section.
An XML document consists of text, and is basically a linearization of a tree structure. At every node in the tree there are several character strings. The tree structure and character strings together form the information content of an XML document. Some of the character strings serve to define the tree structure; others are there to define content. In addition to the basic tree structure, there are mechanisms to define connections between arbitrary nodes in the tree. For example, in the following document there is a root node with three children, with one of the children containing a link to one of the other children:
In this case, the third child contains an href attribute which points to the first child, using its id attribute as an identifier.<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>
The XML linking model is described in the XLL draft <http://www.w3.org/TR/WD-xml-link>. The full hypertext linking capabilities of XML are much more powerful than those of HTML, and are based on more powerful hypertext technology such as described in HyTime [ISO92] <http://www.hytime.org/> and the Text Encoding Initiative (TEI) <http://www.uic.edu/orgs/tei/>. The current specification supports both conventional URLs, and TEI extended pointers. 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) within the same or other documents.
XSL <http://www.w3.org/TR/NOTE-XSL> is a submission defining stylesheet capabilities for XML documents. XML stylesheets enable formatting information to be associated with elements in a source document to produce formatted output. XML stylesheet capabilities are based on a subset of those defined in the ISO standard Document Style Semantics and Specification Language (DSSSL) [ISO96] used in formatting SGML documents. The formatted output is created by formatting a tree of flow objects. A flow object has a class, which represents a kind of formatting task, together with a set of named characteristics, which further specify the formatting. The association of elements in the source document tree to flow objects is defined using construction rules. A construction rule contains a pattern to identify specific elements in the source tree, and an action to specify a resulting subtree of flow objects. The stylesheet processor recursively processes source elements to produce a complete flow object tree which defines how the document is to be presented.
The XML working group is also currently developing a Namespace facility <http://www.w3.org/TR/1998/NOTE-xml-names> that will allow Generic Identifiers (tag names) to have a prefix which will make them unique and will prevent name clashes when developing documents that mix elements from different schemas. This facility allows a document's prolog to contain a set of Processing Instructions (an SGML concept) of the 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 expand to URIs such as http://www.w3.org/schemas/rdf-schema#assertions. This work is still under development, and the details of the final specification may 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 increasingly targeting XML as its "next generation Web representation", the Web object model described in Section 3 uses XML as its basic representation of object state. However, additional concepts must also be defined to apply XML to extended data and metadata structuring requirements, and particularly the requirements for a Web object model that go beyond a richer state representation. Some of these requirements are illustrated both by the relational database example above, and by the RDF and related efforts described in the next section. These efforts generally involve defining data model concepts for representing specific kinds of data (as the relational model does for database data), and then using the tagged value structures supported by XML as their representation. These models support various ways of using identifier concepts (URLs plus other identifier concepts) to provide support for graph structured data. An additional general requirement, not generally addressed by Web-related activities, is the definition of structured database capabilities (e.g., an algebra or calculus to serve as the basis for database-like query and view facilities for XML data).
A data model defines one level of "what to represent". For example, the relational data model defines structuring concepts such as rows and tables, and provides one basic organizational framework for representing data. The example from the previous section of how to represent relational data in XML illustrated how using the relational model imposed additional structure on the XML representation. Defining a data model for data represented in XML both suggests specific structuring concepts for using XML to organize data, and may also involve the specification of certain standard tags or attributes (like <TABLE>) to reflect those concepts. Use of particular data models (represented using techniques such as XML) regularizes the structures that may be encountered, and potentially simplifies the task of applications that process those structures.
An additional level of "what to represent" is provided by standardizing the use of domain-specific attribute/value pairs and document structures (e.g., standards for specific kinds of reports or forms). SGML and XML DTDs constitute one way to specify such standards, and there are already numerous SGML DTDs in use for this purpose (these could, in most cases, be easily adapted for use with XML).
An important source of efforts to develop such higher-level model specifications for use on the Web has been work on developing representation techniques for Web metadata, i.e., data available via the Web that describes or helps interpret either other Web resources or non-Web resources. This metadata is used both to facilitate Web searches for relevant data, and to either provide direct access to it (if it is Web-accessible) or at least indicate its existence and possibly describe how to obtain it. The reason why the development of metadata representations has driven the development of higher-level models is that the metadata is intended to support indexing, searching, and other automated processes that require more structure than may be present in the data itself. Metadata requirements have also driven the development of structured representations themselves. For example, the SOIF format described in Section 2.1.1 was developed to represent Web metadata.
Efforts to develop enhanced metadata capabilities have involved several types of activity (a given effort may bundle more than one of them):
The Warwick Framework has two fundamental components: packages, which are typed metadata sets, and containers, which are the units for aggregating packages.
A container may be either transient or persistent. In its transient form, it exists as a transport object between and among repositories, clients, and agents. In its persistent form, it exists as a first-class object in the information infrastructure. That is, it is stored on one or more servers and is accessible from these servers using a globally accessible identifier (URI). A container may also be wrapped within another object (i.e., one that 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 container itself.
Independent of the implementation, the only operation defined for a container is one that returns a sequence of packages in the container. There is no provision in this operation for ordering the members of this sequence and thus no way for a client to assume that one package is more significant or "better" than another.
Each package is a typed object; its type may be determined after access by 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 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 within the container as a pair of packages. The third metadata set, which defines the terms and conditions for access to the content object, is referenced indirectly via a URI in the container (the syntax for terms and conditions metadata and administrative metadata is not yet defined).
The mechanisms for associating a Warwick Framework container with a content object (i.e., a document) depend on the implementation of the Framework. The proposed implementations discussed in the cited reference illustrate some of the options. For example, a simple Warwick Framework container may be embedded in a document, as illustrated in the HTML implementation proposal; or an HTML document can include a link to a container stored as a separate file. On the other hand, as illustrated in the distributed object proposal, a container may be a logical component of a so-called digital object, which is a data structure for representing networked objects.
The reverse linkage, which ties a container to a piece of intellectual content, is also relevant, since anyone can create descriptive data for a networked resource, without permission or knowledge of the owner or manager of that resource. This metadata is fundamentally different from the metadata that 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 of metadata containers, which both have the same implementation:
Another motivation was the recognition that there are many other kinds of metadata besides that used for descriptive cataloging that may need to be recorded and organized. These kinds of metadata include, among others:
Each rating service picks a URL as its unique identifier, and includes this unique identifier in all content labels the service produces. It is intended 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 to a separate document).
A rating system specifies the dimensions used for labeling, the scale of allowable values for each dimension, and a description of the criteria used in assigning values. For example, the MPAA rates movies in the 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 point values.
Each rating system is identified by a URL. This allows multiple services to use the same rating system, and refer to it by its identifier. The URL identifying a rating system can be accessed to obtain a human-readable description of the rating system.
A content label, or rating, contains information about a document. The format of a content label is defined in the Label Format document referenced above, and has three parts:
When an end-user attempts to access a particular URL, a software filter built into the Web client (browser) fetches the document. The client also accesses the document's content label(s) based on rating systems that the client has been told to pay attention to. The client then compares the content label to the rating-system-specified values that the client has been told to base access decisions on, and either allows or denies access to the document.
Content labels may be:
((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 category has a short transmission name to be used in labels (e.g., "suds"); some also have longer names that are more easily understood (e.g., "Soapsuds Index"). The "Soapsuds Index" category rates soapsuds on a scale between 0.0 and 1.0 inclusive. The "suds density" category can have ratings from negative to positive infinity, but there are two values that have names and icons associated with them. The name "none" is the same as 0, and "lots" is the same as 1. The "document subject" category only allows the values 0, 1, and 2, but a single document 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 following is 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 observation that the PICS infrastructure could be generalized to support arbitrary Web metadata, with PICS categories serving as metadata attributes, having meanings 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:
PICS illustrates a number of important ideas in data modeling and metadata representation. One such idea is the definition of specific required data items (e.g., category, label) having predefined meanings in the model. Such specifications are important in supporting interoperability among applications that use PICS ratings. PICS also illustrates the use of metalevel pointers. The URLs that identify rating services and rating systems in PICS point to information that describes PICS metadata (i.e., to metametadata). These illustrate the idea that a given piece of data on the Web, no matter what its intended purpose (e.g., whether it is intended to represent data or metadata), can itself point to (or be related 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 the Web be interrupted or intercepted, so that rating information about the requested resource can be retrieved, and a decision made about whether to return the requested data or not. This same basic idea can be used to enhance individual requests with other types of additional processing, often transparently to users. For example, such processing could be used to bracket a collection of individual requests to form a database-like transaction, by adding interactions with a transaction processor to these requests. Examples of such processing are described in [CM93, Man93, SW96]. These same ideas are the basis for current OBJS work on an Intermediary Architecture <http://www.objs.com/workshops/ws9801/papers/paper103.html> for the Web.
As illustrated by the existence of a PICS-NG effort, PICS itself requires extensions to deal with more general metadata requirements. Some of these are described further in the discussion of the Resource Description Framework (Section 2.2.6). In addition, in order to provide a complete Web object model, PICS and similar ideas must be augmented with an API providing applications with easy access to the state, and with mechanisms to link code to the state represented using models such as PICS. These aspects will be discussed in subsequent sections.
For example, an XML document might contain a "book" element which lexically contains an "author" element and a "title" element. An XML-Data schema can describe such syntax. However, in another context, it may simply be necessary to represent more abstractly that books have titles and authors, irrespective of any syntax. XML-Data schemas can also describe such conceptual relationships. Further, the information about books, titles and authors might be stored in a relational database, in which case XML-Data schemas can describe the database row types and key relationships.
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 ideas which overlap between syntactic, database and conceptual schemas. All features can be used together as appropriate.
Schemas in XML-Data are composed principally of declarations for:
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:
XML-Data is another example of a higher-level model built using XML as its representation. It is not yet clear how the overlap in metadata capabilities between such representations as DTDs, RDF, and XML-Data will work out. The XML-Data approach may prove to be better than DTDs in supporting some types of processing, such as database-like operations, since it makes no distinctions between data and metadata representations. Like the other data models described in this section, XML-Data is not sufficient to form a complete Web object model. In particular, it requires integration with an API facility and a mechanism to access associated code.
MCF is essentially a structure description language. The basic information structure used is the Directed Labeled Graph (DLG). An MCF database is a set of DLGs, consisting of:
Each label/property type, such as pageSize, is a node (but not all nodes are property types). Since labels are nodes, they can participate in relationships that, e.g., define its semantics. For example, a pageSize node 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 concept of a "Unit" corresponds loosely to the Java concept of "Object".
MCF defines a small set of units with predefined semantics in order to "bootstrap" the type system. These include, among others:
Like PICS, MCF illustrates a number of important ideas in data modeling and metadata representation. For example, MCF illustrates both the use of specific required data items having predefined meanings in the model, and metalevel pointers. Unlike PICS, MCF represents a data model that can be used for more general purposes than content labeling. For example, it includes a type hierarchy, a richer set of base types, and other aspects of a full data model. In addition to required data items representing aspects of the model structure, the MCF reference identifies a list of suggestions for standard application-specific item names borrowed from the Dublin Core and elsewhere. MCF "units" are similar to the individual elements of the OEM model. Many MCF concepts have been incorporated into W3C's RDF (described in the next section). However, as noted in connection with other models in this section, these concepts must be combined with an API and a mechanism for integrating behavior to provide full object model support.
The basis of RDF is a model for representing named properties and their values. These properties serve both to represent attributes of resources (and in this sense correspond to attribute/value pairs) and to represent relationships between resources. The RDF data model is a syntax-independent way of representing RDF statements.
The core RDF data model is defined in terms of:
In this data model both the resources being described and the values describing them are nodes in a directed labeled graph (values may themselves be resources). The arcs connecting pairs of nodes correspond to 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 resource R", or left-to-right; "R has property P with value V". For example 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 identified by 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 nodes is 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 an assertions. Assertions are particularly useful when describing a number of properties of the same resource. Assertions are diagramed as follows:
[resource R]-+---property P1----> [value Vp1] | +---property P2----> [value Vp2]An RDF assertions can be a resource itself and can therefore be described by properties; that is, an assertions can itself be used as the source node of an arc. The name assertions is suggestive of the fact that the properties specified in it are effectively (logical) assertions about the resource being described. This establishes a relationship between RDF and a logic-based interpretation of the data structure which will be further developed in Section 3.
Assertions may be associated with the resource they describe in one of four ways:
The set of properties in a given assertions, as well as any characteristics or restrictions of the property values themselves, are defined by one or more schemas. Schemas are identified by a URL. An assertions may contain properties from more than one schema. RDF uses the XML namespace mechanism to associate the schema with the properties in the assertions. The schema URL may be treated merely as an identifier, or it may refer to a machine-readable description of the schema. By definition, an application that understands a particular schema used by an assertions understands the semantics of each of the contained properties. An application that has no knowledge of a particular schema will minimally be able to parse the assertions into the property and property value components, and will be able to transport the assertions intact (e.g., to a cache or to another application).
A human- or machine-readable description of an RDF schema may be accessed through content negotiation by dereferencing the schema URL. If the schema is machine-readable, it may be possible for an application to dynamically learn 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 value of some other property) or the source node of an arc (i.e. it can have properties). In these cases, the original property (i.e., the statement) must be reified; that is, converted into nodes and arcs. RDF defines a reification mechanism for doing this. Reified properties are drawn as 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 Origin of 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 an additional node (with a generated label) and the three triples with first items (or arcs with labels) using the predefined names RDF:PropName, RDF:PropObj, and RDF:PropValue respectively, second item the generated node label, and third item the corresponding property type, resource node, and value node respectively. In the above example, the three added 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 illustrates the use of
the XML namespace mechanism to qualify names to indicate the schema in
which they are defined.)
Frequently it is necessary to create a collection of nodes; e.g. to state that a property has multiple values. RDF defines three kinds of collections: ordered lists of nodes, called sequences, unordered lists of nodes, called bags, and lists that represent alternatives for the (single) value of a property, called alternatives. To create collections of nodes, a new node is created that is an RDF:InstanceOf one 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 the collection and are uniquely labeled using the elements from Ord. For the RDF:Alternatives, there must be at least one member whose arc label is RDF:1, and that is the default value for the Alternatives node.
The RDF data model provides an abstract, conceptual framework for defining and using metadata. A concrete syntax is also needed for the purpose of authoring and exchanging this metadata. The syntax does not add to the model, and APIs could be provided to manipulate RDF metadata without reference to a concrete syntax. RDF uses XML encoding as its syntax. However, RDF does not require an XML DTD for the contents of assertion blocks (and RDF schemas are not required to be XML DTDs). In this respect, RDF requires at most that its XML representations be well-formed.
RDF defines several XML elements for its XML encoding. The RDF:serialization element is a simple wrapper that marks the boundaries in an XML document, where the content is explicitly intended to be mappable into an RDF data model instance. RDF:assertions and RDF:resource contain the remaining elements that instantiate properties in the model instance. Each XML element E contained by an RDF:assertions or an RDF:resource results in the creation of a property (a triple that is an element of the formal set T defined earlier).
With these basic principles defined, directed graph models of arbitrary complexity 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 updated to use more recent XML namespace syntax). This assertion can be modeled with the directed graph:
[http://www.bar.com/some.doc] ---bib:author---> "John Smith"(This report uses a notation where Nodes are represented by items in square brackets, arcs are represented as arrows, and strings are represented by quoted items.) This small graph can be exchanged in the serialization syntax 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 value are translated into XML.
A more elaborate model could be created in order to say additional things about 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> &