11. Documents and Document Models

Transcription

1 1 of 14 10/3/2005 2:47 PM 11. Documents and Document Models IS October 2005 Copyright  2005 Robert J. Glushko Plan for IO & IR Lecture #11 What is a document? Document types The Document Type Spectrum Using XML to encode models of document types XML Vocabularies Event Calendar Project About the Assignments... What Is A Document? [1]

2 2 of 14 10/3/2005 2:47 PM What Is A Document? [2] A Document is a purposeful and self-contained collection of information This definition focuses on the information content, not on the physical container or medium, format, or technology in which the information is conveyed This broader definition includes information extracted from databases or applications, spreadsheets, printed or web forms, as well as traditional printed documents Document Types Any definition of "document" allows for a notion of different types of documents This idea can be very intuitive and very informal, or we can be more precise and define a model of a document type as the rules or constraints that distinguish one type from another This expression of the model is conceptual and is independent of the syntax and technology in which document instances are ultimately implemented But most of the time the model is ultimately implemented as a physical view in some specific syntax like XML The constraints on structure, data, and behavior of the information in the conceptual and physical models of a document type can collectively be called the Business rules Business Rules "Business Rule" is an up and coming buzzword in information systems that is a lot broader than its name might suggest A Business Rule is a formal or refined statement of an requirement that is expressed in a technology-independent fashion My Taxonomy of Rules Rules that Apply to Conceptual Models Semantic, structural, and usage rules Rules that (Can Also) Apply to Physical Models Syntactic, processing, and presentational rules Rules that Apply to Instances

3 3 of 14 10/3/2005 2:47 PM Content rules Semantic Rules Establish properties: "The Order Number is an identifier that is unique to the Buyer" Express generalizations: "An Auto is a type of Vehicle" Expose dependencies: "The Price of an Item can depend on the Buyer" Structural Rules Define co-occurrence or aggregation relationships between components "Each Illustration must have a Caption" "Every Order must have an Order Number, a Buyer and an Issue Date" Usage Rules Define policies or privileges governing access to information Often based on organizational roles or responsibilities "An Employee Salary can be viewed by a Manager but can only be changed by someone in the Human Resources Department" Syntactic Rules Concern the form in which models are encoded Might specify a particular XML vocabulary "All Purchase Orders must be encoded according to ANSI X12 850" "All Purchase Orders must conform to the Universal Business Language" Processing Rules Define actions to be taken whenever a given condition occurs or set of information is encountered Also called Procedural or Behavioral rules

4 4 of 14 10/3/2005 2:47 PM "The Seller will respond to an Order with an Order Response" "If the Item is Out of Stock, create a Back Order Request" "If the Customer Account Balance is greater than $1000, do not allow any more purchases" Presentation Rules Govern the appearance or rendering of an information component "The Item Description must be adjacent to the Product Image" "The Title should be centered" Content Rules Establish constraints about the values of information components or dependencies among them "The Total Value of an Order cannot exceed $100,000" "The Currency Code should be expressed using ISO 4217 codes" "The Shipping Address must be the same as the Billing Address" "The Start Date must be earlier than the End Date" "The Customer's Account Balance must be greater than 0" Combined Rule Types "If the Purchase Order Amount exceeds $10000, the Party must supply a Duns Number" "If the Customer's Account Balance exceeds $1000, display it in Red" "If the Customer's Account Balance exceeds $10000, send a Past Due Reminder by , fax, and voice mail" Patterns of Business Rules Document types differ in the mixture of business rules from these seven categories Put another way, the mixture of rules determines the kind of document type it is Transactional documents have many semantic, usage, processing, and content rules

5 5 of 14 10/3/2005 2:47 PM Narrative documents tend to have more structural and presentational rules The mixture of these business rules varies in systematic ways across the "spectrum" of document types The Document Type Spectrum [1] The Document Type Spectrum [2] "Narrative" Document Types (or "Publications") Examples: Novels, user guides, technical manuals,... "Transactional" Document Types Examples: Orders, invoices, payment instructions,... In between are "Hybrids" Examples: Dictionaries, catalogs,... XML Schemas XML schemas attempt to encode the conceptual model for a document type in terms of the syntactic constructs of elements and attributes What elements are allowed (the vocabulary) Where the are allowed sequence, choice, occurrence and co-occurrence (the grammar) What values they can take (datatypes) string, integer, decimal, etc.

6 6 of 14 10/3/2005 2:47 PM Figures 2-3a and 2-3b in the Document Engineering reading encode the model of the "simple event calendar" document type using two different schema languages, "Document Type Definitions" (DTDs) and "XML Schemas" (XSD) DTD for Simple Event Calendar <!ELEMENT Calendar (Organization, TimePeriod, Events)> <!ELEMENT Organization (#PCDATA)> <!ELEMENT TimePeriod (#PCDATA)> <!ELEMENT Events (Event+)> <!ELEMENT Event (Title, Description?, Speaker?, DateTime, Location)> <!ATTLIST Event type (Lecture Workshop) #IMPLIED> <!ELEMENT Title (#PCDATA)> <!ELEMENT Description (#PCDATA Keyword)*> <!ELEMENT Keyword (#PCDATA)> <!ELEMENT Speaker (Name, Affiliation)> <!ELEMENT Name (#PCDATA)> <!ELEMENT Affiliation (#PCDATA)> <!ELEMENT DateTime (#PCDATA)> <!ELEMENT Location (#PCDATA)> XML Schema for Simple Event Calendar <xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:element name="calendar"> <xs:complextype> <xs:sequence> <xs:element name="organization" type="xs:string"/> <xs:element name="timeperiod" type="xs:string"/ <xs:element name="events"> <xs:complextype> <xs:sequence> <xs:element name="event" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="title" type="xs:string"/> <xs:element name="description" minoccurs="0"> <xs:complextype mixed="true"> <xs:choice minoccurs="0" <MaxOccurs="unbounded"> <xs:element name="keyword" type="xs:string"/> </xs:choice> </xs:complextype> </xs:element> <xs:element name="speaker" minoccurs="0">... XML Vocabularies

7 7 of 14 10/3/2005 2:47 PM When a model of a document type is encoded in XML it is often called an XML "vocabulary" or XML "application" But this conflicts with the more common usage of that word to mean "software application" so I try to always use vocabulary The best thing about XML is the ease with which anyone can create a new vocabulary Why XML Vocabularies Exist Vocabularies must exist because: XML has no predefined set of tags And since there is no predefined tag set, there can't be any predefined semantics Semantics are defined in the schema and its documentation about what the elements and attributes mean So using XML without a (documented) schema makes little sense Why Vocabularies Are Desirable Vocabularies are desirable because people want to have a set of tags that is customized to their problem or industry so that they can take full advantage of XML A good vocabulary represents a significant investment in defining a domain, identifying its key semantic components, and specifying the constraints and rules governing the combination and reuse of those components A good vocabulary is a reference model for the domain that facilitates communication between enterprises operating within it XML and Metcalfe's Law The value of a language depends on how many people (or computers) understand it How do you encourage and enable others to understand your language? Standardization Approach 1: "Understand my language or I won't do business with you" Standardization Approach 2: "Excuse me, here's my language, would you like to do business with me?" Vertical and Horizontal Vocabularies

8 8 of 14 10/3/2005 2:47 PM Vertical: Horizontal Particular industry or vertical market Detailed product semantics Specialized process semantics Sometimes called "domain-specific" languages Concepts that are common to all (or a large number of) vocabularies (for example, UBL) Vocabularies that are related to software infrastructure (for example, SOAP) Vocabularies that are "pure" metadata for resource or ontology description (for example, RDF, OWL) The Worst Thing About XML Is the same as the best thing: the ease with which you can create a new vocabulary There are often multiple vocabularies for the same or related domains and especially for the common information models that are used in more than one domain That two concepts use the same XML tag names doesn't prove anything; the same content will inevitably be described using different names, and different content will be given the same names Search for an existing vocabulary before you start proliferating yet another one! Vertical and Horizontal Vocabularies Must Work Together Different industries need specialized terms and properties to describe their products and processes, but if they don't build them on top of a standard base document, there will be no interoperability across industries

9 9 of 14 10/3/2005 2:47 PM Attacking the Interoperability Problem Everyone has to learn to "speak" all the languages clearly impractical Everyone has to learn just one language but it has to be the same one Multiple vocabularies exist, but there is at least one "interchange" or "hub" language designed to facilitate translations between "native" vocabularies The Berkeley Event Calendars Project Started as homework assignment in Spring 2003 Document Engineering, became SIMS Final Project in 2004, finally being implemented and deployed this year The problem - scores of calendars on berkeley.edu with overlapping coverage and audiences but incompatible data models No automated reuse of information; you need to submit events to multiple calendars or copy events from them Each calendar has a different event submission form and a different model of an event Typical of problems that occur in every large organization with timesheets, expense reimbursement, registration, etc. and also representative of B2B interactions with incompatible catalogs, orders, etc. A Sample of Event Calendars Official university calendar ( Academic departments ( and schools (

10 10 of 14 10/3/2005 2:47 PM Research centers and institutes Student organizations Sports ( Performances Libraries and museums University official dates (academic calendar, admissions, financial aid) ( Events Calendar Project Goals Create an overall conceptual model that could describe every event taking place on campus Eliminate (or encourage the migration from) incompatible calendar models and applications Enable the creation of new types of calendar documents that assemble events for different contexts Event Calendar Network: Conceptual Architecture

11 11 of 14 10/3/2005 2:47 PM Event Calendars: Analysis Strategy What can we learn from a specific calendar instance? What can we learn from an "add new event" forms like this one ( or or this one ( But you also have to look at instances and forms in combination Harvesting and Consolidation Harvesting Create a set of candidate content components by extracting them from the information sources while removing presentation and structure Consolidation Identify synonyms and homonyms among the candidate content components, assigning a unique name to each unique meaning as part of a controlled vocabulary Event Calendars: Harvesting and Consolidating Components Synonyms: Start Date Homonyms: Commencement Contact (person submitting an event) Contact (person to contact about an event) Category / Type (disjoint domains: events, attendees) Event Calendars Consolidated Table of Candidate Components

12 12 of 14 10/3/2005 2:47 PM Event Calendars: The Conceptual Model The conceptual model of the event calendar is a set of relationships between information components From this model we can assemble any of a set of related document types for different varieties of event calendars Time-based: the usual calendar; what events take place on this day? Location-based: what events are taking place in South Hall? Event-based: list of events; academic calendar The Event Conceptual Model

13 13 of 14 10/3/2005 2:47 PM Simplified Conceptual Model Alternate Assemblies

14 14 of 14 10/3/2005 2:47 PM About the Assignments... Review of Assignment 3 (and 4) Assignment 5: Document Types for a Day (as scheduled) Assignment 7 cancelled; Assignment 8 will be a writing assignment Assignment 9 will not be graded but will support Assignment 11 SUMMARY: Two fewer assignments Readings for IO & IR Lecture #12 GUEST LECTURER: RAY LARSON "Introduction (part of SQL for Web Nerds)" Philip Greenspun "Introduction to Relational Databases" Ian Gilfillan Database Journal (24 June 2002)