Presentation is loading. Please wait.

Presentation is loading. Please wait.

DITA Enterprise Content Metamodel

Similar presentations


Presentation on theme: "DITA Enterprise Content Metamodel"— Presentation transcript:

1 DITA Enterprise Content Metamodel

2 Introduction

3 Objectives Develop a universal metamodel to describe typical business document content Identify reusable semantic structures with a compatible granularity to the DITA standard Describe a framework for adoption of a DITA standard for enterprise business documents

4 Scope The metamodel is designed specifically for business documents
Business documents represent a specific subset of business records used within an enterprise Business documents are typically controlled requiring revisions and approvals They may be internal or external customer-facing materials The model attempts to integrate with rather than replace existing information systems The model is not intended to dispense with vast amounts of dissimilar or unstructured information used within an enterprise

5 Business Documents Policies and procedures
Typically include controlled items such as: Typically do not include items such as: Policies and procedures Product development/maintenance documentation Technical publications Sales and marketing materials Memoranda and correspondence Newsletters and social media Third-party materials Database and financial output These items along with business documents represent business records

6 Research Content Models Document Models Business Object Models
Information Mapping™ DITA Document Models Military Specifications (S1000D, 2361, 2167, 498) ISO (9000, 15489) Business Object Models Rational Unified Process/Unified Modeling Language Zachman Framework Information Technology Infrastructure Library (ITIL)

7 Nature of Business Documents
Business documents are typically a conglomeration of different types of information written narratively with little consideration for semantic structure Business documents require extensive metadata for proper administrative management and retrieval Business documents are typically process-driven arising from specific events or handoff in the process Business documents often contain or reference content created earlier in the process While there are no widely adopted standards for content models, there are typical document types and recognizable structures in most business documents

8 Single-Source Authoring
Single-source authoring practices have reached a state of maturity within technical publications well beyond those in business documentation Repeatable single-source authoring practices enable collaboration on content creation Single-source authoring improves content quality, consistency, and maintainability Single-source authoring requires a level of sophistication that eludes most business users

9 Granularity Granularity of reuse within business documents appears to be more complex than in typical technical publications Size of reusable components varies from a single-statement to collections of nested topics Application of reusable components may be used across far more diverse audiences Granularity must be defined as well by the ownership and lifecycle of the component within the metamodel Information must be captured into a single source and managed according to robust rules for reuse using progressive disclosure to determine the granularity

10 Traceability Businesses use many purpose-built applications and databases to manage business information such as: Requirements management tools Bug tracking systems Software testing tools These systems contain content that can make its way into documents and reports used across the enterprise They also contain traceability used to validate the information, provide notification, and trigger changes The metamodel should incorporate traceability for business documents to integrate with these systems

11 Knowledge Management Knowledge is rarely captured directly in business documents and is most often compiled indirectly by document authors Information is gathered from multiple sources and subject matter experts and distilled into documents before it is thrown over the wall – the information is written and forgotten about Over time, the knowledge loses relevance or is lost The metamodel breaks content down into manageable chunks that can be controlled by the subject matter experts and compiled into traditional documents

12 Accountability A convergence of factors are driving business towards solutions that make management of information within their enterprise more effective Process certification, regulatory requirements, needs for improved efficiency and quality push the demand for better controls over how information is managed These demands require better metadata, finer granularity of information, centralization, process automation, information ownership and traceability The metamodel breaks information down into chunks that can be accountable to appropriate role-based functions within the enterprise irrespective of how or when the information is published

13 Enterprise Content Management

14 Evolution of the Enterprise Topic
What is a topic? Topics are the fundamental building blocks used to capture knowledge about any given subject Topics represent a single source of information within a repository Topics are designed to be used and reused in their entirety or in part through progressive disclosure Topics are independent of any containing document or map and can be used in any appropriate context Topics naturally fit within a global ontology describing the enterprise and are traceable to other topics

15 Content Classes

16 Content Lifecycle Output: Information Product
There are three main parts in the model: 1. The input: Information Objects The writer (or information owner) creates an information object. It’s labelled with a unique ID and put into the database. 2. The repository: Information Core All objects go into the repository. The people controlling changes in the repository will make sure the information does not conflict with other information there. 3. The Output: Information Products Users can still get traditional paper print-outs. But this time, the user can put together a combination of information pieces that suits their own needs and in the form they want. Output: Information Product Repository: Information Core Input: Topics

17 Reusability Example 1: Reorganizing objects into custom-ordered manuals You might have a whole bunch of Information objects spread throughout the database called ‘Policies’ -- policies for the Help Desk, policies for Change Management, etc. You can easily collect them all together into one Policy guide. You don’t need to re-write a whole new Policy guide. This is a great tool for managers looking for dated, missing or even conflicting policies. Because these are sourced from a "living document" managers know they are referencing only current information. Example 2: Accessing up-to-date information Instructions are very specific procedures for using a tool. We could put this right in the tool's online help system. By posting this object in the Repository, the tool's online help system can access the information directly across the network. Example 3: Publishing high-level information Other information sources, such as InTireNet can link to information in this Repository. For example, InTireNet users can see what groups are responsible for what tasks in the Department. (You’ll remember that staff identified the issue ‘Improve Communication Flow’ in the EOS survey.)

18 Traceability Example #1: Change from the top-down
In reviewing the Policy Manual, a manager realizes that a policy is no longer in keeping with the Corporate philosophy. They change the policy. This change to Incident Ownership policy removes ownership from the Help Desk Analyst and places it into the hands of the Local Administrator. This policy change prompts a change in the process. The process prompts a change in procedure and a change to the Local Administrator role. The instructions are not impacted so they are not changed. As a result of the change in role, other documents referring to that role are updated at the same time. Example 2: Change from the bottom-up Axios issues a patch that changes the assyst tool. (e.g. The operator can no longer set the priority -- it is now pre-set automatically or by an administrator.) Since the field is no longer accessible, we update the instruction this change modifies the procedure the change in procedure modifies the process this change in process reaches the policy level where the policy owner is made aware of the limitation imposed by the tool the policy owner may choose to amend the policy or issue a change request to fix the tool the owner decides not to change the policy but instead comes up with a work-around until the tool is changed this decision will cascade back down the list until it reaches the Instruction where the instruction is modified to reflect the workaround.

19 Modeling Enterprise Content
The model started as a map of dozens of dissimilar types of content found within an enterprise linked in various ways through traceability For example RFP elements were linked to proposal elements Proposal elements were linked to requirement elements Requirement elements were linked to design elements Design elements were linked to specification elements Specification elements were linked to procedural elements As information changed in one element, other elements within the chain were impacted

20 Boiling the Ocean As the content types were boiled down by matching similarities between the types, a common set of 11 base content types emerged along with common dependencies These content types formed within an elegant symmetry to answer the basic questions of who, how, what, why, when and where The three primary DITA information types of concept, task, and reference stood out clearly among the 11 base types within the metamodel

21 Gathering of Information Types
Why? Objectives Who? Resource Ability Activity What? Requirement Design Reference How? Concept Governance Task Event When? Objective Where? Resource

22 Enterprise Content Metamodel
Why? Objective Who? How? What? Standard DITA Proposed Resource Concept Requirement Governance Ability Activity Task Reference Design Where? Resource Event Event Event Objective When?

23 Task-based Information
Concept The Task information type is central to the model Task describes how something is performed Reference describes the tools used in the Task Task produces an Event Activity describes what is to be performed by the Task Governance describes limitations on the Task Concept provides terms for Governance Governance Activity Task Reference Event

24 Task Type Description Dependencies Examples
Concept Governance Event Reference Activity Description Based on the DITA Task topic type Describes one or more steps needed to accomplish an action Dependencies Reference Governance Activity Event Examples User procedures and Instructions Processes Test cases

25 Task Construction Sample Markup Sample Content Log onto the network
Concept Governance Event Reference Activity Sample Markup <task> <title></title> <shortdesc></shortdesc> <taskbody> <prereq></prereq> <steps> <step><cmd> </cmd></step> </steps> </taskbody> <related-links></related-links> </task> Sample Content Log onto the network Once logged on to the network, you will be able to work online. You must have received log-in details from IT before proceeding with your log-in attempt. Caution: Do not attempt to log onto the network without current login credentials. 1. Press <CTRL> + <ALT> + <DELETE> 2. Enter user name and password 3. Click Enter See also: Login Attempts

26 Event Type Description Dependencies Examples Describes an event
Concept Governance Activity Task Reference Description Describes an event Consists of an event along with optional date/time, place, summary, description, status, acceptability, and recommendation Dependencies Task Objective Examples Test results Problem/incident report Activity report Event

27 Event Construction Sample Markup Sample Content Login attempt failed
Concept Governance Activity Task Reference Sample Markup <event> <title></title> <summary> <date/> <location/> </summary> <eventbody> <eventdetails></eventdetails> <acceptability></acceptability> <recommendations></recommendations> </eventbody> <related-links/> </event> Sample Content Login attempt failed 10/03/2008: User was unable to log onto the network with verified login credentials. User attempted to log onto the OASIS network through Abacus using his most recent login information contained in a system . The system gave the user the following error message: ERROR: Cannot log onto DNS server. User account mismatch on file. This is not the expected behaviour for a user login. Check the PKI domain tables to ensure the settings are correct for this user. See also: QA Steps to reproduce error Event

28 Governance Type Description Dependencies Examples
Concept Governance Activity Task Reference Description Applies conceptual information providing guidance or limitations on performing Tasks Consists of a statement along with optional conditions, scope, remedies, consequences, and background information Dependencies Concept [Parent]: Changes may prompt changes to Governance Task [Child]: Changes to Governance may prompt changes to Task Examples Cautions, warning, and notes Policies Guidelines Event

29 Governance Construction
Concept Governance Activity Task Reference Sample Markup <governance> <title></title> <statement></statement> <govbody> <conditions></conditions> <penalties></penalties> <remedies></remedies> </govbody> <related-links/> </governance> The Governance information type as it is being defined within the focus area. Sample Content Login Attempts Do not attempt to log onto the network without current login credentials. After 10 failed login attempts, the system will lockout your workstation and prevent it from connecting to the network. If your workstation is locked out, contact the IT Service Desk for assistance. See also: Log onto the network Event

30 Concept Type Description Dependencies Examples
Governance Activity Task Reference Description Based on the DITA Concept topic type Defines and explains terms used Dependencies Objective [Parent]: Changes may prompt changes to Concepts Guidance [Child]: Changes to Concept may prompt changes to Governance Examples Definitions Industry Standards Whitepapers Event

31 Concept Construction Sample Markup Sample Content Secure Passwords
Governance Activity Task Reference Sample Markup <concept> <title></title> <shortdesc></shortdesc> <conbody> <paraclass/> </conbody> <related-links/> </concept> The Concept information type is based off of the DITA Concept topic. Sample Content Secure Passwords Secure passwords ensure that intruders are unable to assume your identity and compromise network security. Secure passwords can take many forms. Generally, passwords should be more than six characters long, any less and the ability to crack the password increases by 425%, according to NetSpy. Consider passwords that include a mix of alpha characters and numbers. See also: Network Password Policy Login Attempts Event

32 Resource-based Information
Task Concept Governance Event Reference Activity Resource Activity describes what is to be performed Activity is performed by a Resource Activity requires a certain Ability Resource possesses given Ability Ability Activity

33 Activity Type Description Dependencies Examples
Resource Ability Activity Description Describes what needs to be accomplished and criteria for measuring performance Does not describe “how” it is to be done (see Task) Consists of an item along with optional summary, description, constraints, and evaluation criteria Dependencies Resource [Parent]: Changes to Resource may prompt changes Ability [Child]: Changes to Activity may require new Abilities Task [Child]: Changes to Activity may require new Tasks Examples Job description Service Level Agreement Action items

34 Activity Construction
Resource Ability Activity Sample Markup <activity> <title></title> <shortdesc></shortdesc> <activitybody> <details></details> <constraints></constraints> <criteria></criteria> </activitybody> <related-links/> </activity> Activity and Governance types are very similar. The main distinction is that an Activity applies to a Resource whereas a Governance type applies to everyone and is not specific to any Resource. An Activity is a commitment made by a Resource. Sample Content Setting Up Account for New Hires Network accounts are to be set up prior to the first day of work for new-hires. New accounts are created when triggered by the New Hire Process. A problem ticket will arrive and be resolved by the IT Service Desk. New hires that are not subject to the New Hire Process may not have accounts set up during their first week of work. The IT Service Desk requires seven-days notice for new account setup. See also: Service Desk Specialist

35 Resource Type Description Dependencies Examples
Ability Activity Description Identifies a Resource within an organization May be a named person, job role, department, or other group of related persons Consists of a name along with optional details and hierarchy Dependencies Objective [Parent]: Changes to Objectives may modify Resources Activity [Child]: Resources are responsible for given Activities Ability [Child/Parent]: Resources possess and/or require Abilities Examples Biographical information Description of organization Contact record

36 Resource Construction
Ability Activity Sample Markup <resource> <name></name> <shortdesc></shortdesc> <resourcebody> <details></details> <characteristics></characteristics> </resourcebody> <related-links/> </resource> Because a Resource can describe any number of individuals or groups there is not a lot of semantic structure. In its basic root form, the body would be similar to that of a concept body. The semantics are introduced through specializations into topics describing departments, individuals, or roles. The hierarchical position of this topic placed within other Resource type topics is very significant indicating reporting relationships within an organization. Sample Content Service Desk Specialist The Service Desk Specialist is a member of the IT Service Desk. This role is typically the first-line of response to customer inquiries and complaints. The Service Desk Specialist reports to the Service Desk Shift Supervisor and may be responsible for supervising Co-Op placements and new-hires. Core competencies: English/French, Fluent Spoken, Intermediate ITIL Certification Services include: Registering Incidents, Setting Up Accounts See: Sue Green

37 Ability Type Description Dependencies Examples
Resource Ability Activity Description Describes level of competency required for performing tasks Consists of a competency along with optional summary, description, level, and evaluation criteria Dependencies Resource [Parent/Child]: Resources possess and/or require Abilities Activity [Parent]: Changes to Activities may require changes to Abilities Examples Competency matrix Employee evaluation Training plan

38 Ability Construction Sample Markup Sample Content Multilingualism
Resource Ability Activity Sample Markup <ability> <title></title> <shortdesc></shortdesc> <abilitybody> <details></details> <constraints></constraints> <criteria></criteria> </abilitybody> <related-links/> </ability> Ability topics are semantically similar to Activity topics in their base state. Additional semantic detail can be introduced through specialization. As with the Resource type, Ability topics are very hierarchical with peer and sibling topics indicating levels of ability. Sample Content Multilingualism An ability to communicate in more than one language. At ABC, Corp. employees may be required to work in the native language of our customers and partners. Competency levels are divided by the number of languages and fluency in each language. Languages spoken at ABC, Corp. other than English include: French, Cantonese, and Spanish Competency Levels: English/French, Fluent Spoken English/French, Fluent Written Spoken

39 Product-based Information
Task Concept Governance Event Reference Activity Resource Ability Requirement Reference describes a tool and its benefits and features Design describes how the tool is built to Requirements Requirement governs Design and functionality Reference Design

40 Reference Type Description Dependencies Examples
Requirement Reference Design Description Based on DITA Reference topic type Describes details, features, and/or facts about an object Dependencies Requirement [Parent]: Changes to Requirements may produce gap specifications Design [Parent]: Changes to Design may prompt changes to the Reference topic Task [Child]: Changes to the Reference may prompt changes to related Tasks Examples Product specification Screen capture with callouts Publication specification

41 Reference Construction
Requirement Reference Design Sample Content PM_1202: Network Login Dialog Dialog permits users to enter account credentials and submit them for network verification to establish a connection. ┌─User Login ───────────────────┐ │User:_________________________ │ │Password:_____________________ │ │ SUBMIT CANCEL │ └───────────────────────────────┘ Field Description Note User Enter name Not Case Sent Password Enter password Case Sensitive API Calls The dialog can be accessed using the following API call: LaunchLogDia.Run.UI See also: PMCS 90022: NetLog.corba Sample Markup <reference> <title></title> <shortdesc></shortdesc> <refbody> <example></example> <characteristics></characteristics> <section></section> </refbody> <related-links/> </reference> The hierarchical arrangement of Reference topics to describe base-line functionality of a system is significant.

42 Design Type Description Dependencies Examples
Requirement Reference Design Description Explains how something is designed to work Does not describe how it is (see Reference) Consists of an item along with optional inputs, outputs, parameters, description, limitations, and logic Dependencies Requirement [Parent]: Changes to Requirements may prompt changes to the Design Reference [Child]: Changes to Design may prompt changes to the Reference topic Examples Preliminary/Detailed Design Logic diagrams Content Plan

43 Design Construction Sample Markup Sample Content
Requirement Reference Design Sample Markup <design> <title></title> <shortdesc></shortdesc> <designbody> <paraclass/> </designbody> <related-links/> </design> Design topics represent information used by developers, and product designers to create products. It describes how something works on an abstract level. This can represent a large number of specializations to accommodate design of software, hardware, drugs, publications, etc. At its most basic level, there are few specialized elements. Sample Content PMCS 90022: NetLog.corba Module displays login dialog and submits data to DNS server for routing. Inputs userName.pki userPass.pks Interface DNSPass.pk.corba Logic Function NetLog() { Go.Log(userName,userPass); If Go.Log = “Pass” then { Goto.DNSPass; } else end; See also: PM_1202: Network Login Dialog

44 Requirement Type Description Dependencies Examples
Reference Design Description Describes what an object must do Does not describe what the object does (see Reference) nor how it should do it (see Design) Consists of a statement along with optional description, parameters, dependencies, performance and ranking Dependencies Objective [Parent]: Changes may prompt changes to the Requirement Design [Child]: Changes may prompt changes to the Design Reference [Child]: Changes to the Requirement may prompt changes to the Reference topic (particularly where there is no Design) Examples Product Requirement Specification RFP elements User needs analysis

45 Requirement Construction
Reference Design Sample Markup <requirement> <title></title> <need></need> <reqbody> <details></details> <constraints></constraints> <criteria></criteria> </reqbody> <related-links/> </requirement> Service objects and Governance objects are very similar. The main distinction is that a Service object applies to a Resource whereas a Governance object does not apply to a specific Resource as it applies to everyone. A Service is a commitment made by a Resource. Sample Content Unique User Login Each user must be able to log onto the network using a secure password and assigned user name. Before working on the network, the user must submit a valid login to the network server for validation. The system shall provide appropriate user-feedback for incorrect login attempts. Group logins shall not be permitted. If the user repeatedly fails login attempts, the system shall prevent further connection attempts. See also: PM_1202: Network Login Dialog PMCS 90022: NetLog.corba

46 Business-based Information
Objective describes the goals, business reasons, or mission affecting change Objective Resource Concept Requirement Resources, Concepts, and Requirements are suited to meet an Objective Objectives may be related to previous Events Task Concept Governance Event Reference Activity Resource Ability Requirement Design Event

47 Objective Type Description Dependencies Examples
Resource Concept Requirement Description Describes the goals of an organization, project, product, or idea Consists of a goal along with optional description, evaluation criteria, target date Dependencies Resource, Concept, and Requirement [Child]: Changes to an Objective may prompt new child topics Event [Parent]: Results may alter or prompt for new Objectives Examples Project planning elements Employee performance plan Corporate charter

48 Objective Construction
Resource Concept Requirement Sample Markup <objective> <title></title> <goal><goaldate/></goal> <objectivebody> <details></details> <constraints></constraints> <criteria></criteria> </objectivebody> <related-links/> </objective> Sample Content Improve IT Security Practices Q2 2009: Corporate IT will develop new policies and procedures to improve security practices in preparation for ISO:27001 audit.

49 Abstract Information Types
Upon examination of the semantic substructures for these 11 content types, we identified similarities between several of the types precipitating the creation of 6 abstract information types The abstract information types are derived directly from the base topic type and form the basis for all information contained within the model Explanatory Procedural Descriptive Directive Criterial Temporal

50 Inheritance from Abstract Layer

51 Procedural Information used to instruct the reader on the steps required to perform a task Underlies the <task> topic, among others <procedural> <title> <shortdesc> <taskbody> <prereq> <context> <section> <process> or <steps> <result> <example> <postreq> <related-links>

52 Explanatory Explains an idea or concept
It may define how something works, how something is made, or what something is Underlies the <concept> and <glossentry> topics, among others. <explanatory> <title> <shortdesc> <expbody> <example> <related-links>

53 Descriptive Describes specific information about an object
It may describe characteristics of an object, a person, or a place It may include pictures or illustrations of the item at a given point in time Underlies the <reference> topic, among others <descriptive> <title> <shortdesc> <descbody> <detail> <sublist> <characteristics> <related-links>

54 Directive Information used to direct or limit performance of a procedure The statement is backed up with information to help the user understand the consequences and resolution of performance relative to the statement <directive> <title> <statement> <directbody> <detail> <sublist> <conditions> <exclusions> <penalties> <remedies> <related-links>

55 Criterial Information used to specify criteria that are measurable or comparable to other pieces of information Allows for comparison of what was needed versus what was delivered <criterial> <title> <shortdesc> <critbody> <detail> <sublist> <constraints> <criteria> <related-links>

56 Temporal Information that reports on an event
Records specific time and/or place of the occurrence and summarizes the outcome <temporal> <title> <summary> <stamp> <date-time> <location> <occurrence> <tempbody> <details> <sublist> <related-links>

57 Business Content Specializations

58 Aggregated Business Documents

59 Metadata Requirements
Metadata requirements break down across 5 main categories: Administrative Metadata Metadata for Search and Retrieval Metadata for Categorization Metadata for Processing Metadata for Indexing


Download ppt "DITA Enterprise Content Metamodel"

Similar presentations


Ads by Google