Knowledge Management at the Datum Level

1
Knowledge Managementat the Datum Level

• Trish Laedtke
• Project Manager
• DataChannel/ISOGEN International
• Austin, March 2000

2
XML in Knowledge Management

• Phenomenal acceptance across industries
• Used for structuring data
• Used for transferring information
• New applications available weekly
• Limitations in Knowledge Management
• Legacy applications and data stores
• Non-XML like data.
• Engineering drawings
• Video
• Etc.

3
Knowledge Management

• Historically known by a variety of other names
• Document Management
• Product Data Management
• Content Management
• Data warehousing/mining
• All are wrestling with data management functions
• Access
• Relationships
• Access
• Version management
• Access

4
Knowledge Management

• Key to all of these is knowing what data to
  access, by whom, when
• This capability must be driven below the file
  level. -- i.e., pieces of data within a document
  are the drivers
• For access
• For reuse
• For process
• The possibilities for increased functionality are
  exponential
• The gains are too valuable to ignore

5
History of Product Data Management

• PDMs became popular in the mid-90s for
  management of engineering information regarding
  parts, assemblies, and products
• Similarity to Document Management Systems (DMS)
• Application sitting on a database
• Manages object versioning, relationships, and
  workflow/process
• Provides the ability to track development and
  decision history
• Access is increasingly web-based, but few files
  are viewable without downloads.

6
PDMs (cont.)

• Differences from DMS
• Diverse data or file types, some of which cannot
  be dealt with as XML
• Engineering CAD/CAM/CAE
• Miscellaneous supporting documentation
• Diverse types of users
• Multiple types of relationships
• Integration with other systems highly probable
• ERP
• DMS
• Closed, controlled system--imposed limits

7
Traditional PDM Example

• Company A manufactures Whatsits.
• Engineer creates whatsit.dwg.1 in a CAD
  application.

8
Traditional PDM Example (cont.)

• Support departments create supporting
  documentation.
• May be Microsoft Word
• or other publishing
• formats.
• May be financial
• or parts
• database info.

9
Traditional PDM Example (cont.)

• Meanwhile, changes occur in the design of Whatsit.

10
Traditional PDM Example (cont.)

• Change is needed in the supporting documentation,
  new versions are created

11
Traditional PDM Example (cont.)

• Similar products are created

12
Problems with Traditional PDM System

• Relationships are built only at the file level
• Cannot relate parts within drawings to text
  within a supporting document
• Cannot track change between versions of a file
  and the resultant change needed in supporting
  documentation
• Cannot search file content, must rely on metadata
• Change causes rework in multiple applications, by
  multiple users

13
Problems with Traditional PDM System (cont.)

• Heavily dependent on notification, often
  requiring employees to intervene in process
• Expensive software and time/resource
• Interchange, being addressed by PDM Elaborations
  group

14
Key to Redefining Data Access

• Data, is Data, is Data
• Files are data
• Metadata is data
• States are data
• Relationships are data

15
Groves

• ISO/IEC10744 A formalized public international
  standard representation
• Provides a common object model, allowing
  information in many notations to be addressed in
  a common fashion, even if the sources from which
  groves were generated were not.
• Enables effective processing of very large
  collections of structured content.

16
Groves Are Uniform!
17
Basic Assumptions about Groves

• Groves provide a generic form of data abstraction
• Nodes with properties organized as trees or
  graphs
• Simple, consistent API independent of data type
  details
• Standardized syntaxes and semantics for
  addressing HyTime, SDQL, XLink (TBD)
• Any kind of data can be mapped to a grove
  representation

18
PDM Groves

• Diverse types of data can be normalized using
  Property Sets
• Property sets can be reused between different
  instances of data types
• different data sources present same grove
  representation
• Opens access to data, not just metadata
• Allows for addressing between disparate data
  types
• Generation of new data or initialization of
  processes based on known data
• Groves are not implemented for the sake of groves
  but as the means to a multitude of value-adding
  ends

19
Access to All Data

• Removes reliance on and limits of metadata
• Searching
• Combined with relationships, better sense of
  applicability
• Normalizaton of data using groves
• allows access to data itself

• Metadata
• Author
• Creation date
• Revision info
• Identification
• Key words
• Abstract

20
Conversion to Other Formats

• Enables access to data without the originating
  software, by removing the proprietary format
• Allows a single grove aware process to output
  from several different formats

21
Relationships at the Data Level

• Allow the relationship of parts within drawings
  to text within supporting documentation
• Addressing via HyTime or Xlink/Xpointer
• NOTE only applicable parts of data need to be
  converted to groves

22
Added Automation Capability

• Masters can be established in appropriate
  application and be used as key data for other
  files
• Changes in master files are noted, and related
  info is updated

23
Allows Creation of New Information

• Data from diverse formats can
• be combined and
• normalized, then
• converted to another
• structured data format,
• e.g., SGML/XML and
• combined to create new
• information products

24
Data Transfer Between Systems

• Files, metadata, and relationships can be modeled
  in groves, converted to an interchange format,
  e.g., XML
• Namespaces
• Architectures

25
Degrees of Implementation

• Groves are built and
• stored external to the
• PDM. Could serve as
• the users main
• point of access to data.

26
Further Integration

• Groves are stored and managed along with the
  source data.
• Relationships can exist between data in groves
  within the PDM.

27
An Idealist Approach

• Given the right infrastructure (resources and
  OS), groves could become The PDM in a bounded
  file-system.
• Access and storage/lock mechanisms
• Simple GUI for users
• Minimal controls imposed
• Workflow versioning/tracking

28
An Idealist Approach
29
Advantages to Groves in PDM

• In and of themselves, groves can be used to open
  data normally not available to the user or system
• Once data is open, other standards can be
  applied to add more value and functionality to
  data
• XSLT
• HyTime
• DSSSL
• Etc.

30
STEP/SGML Harmonization

• Attempt to formally define relationship between
  STEP (ISO 10303) and groves
• Enable automatic grove representation of STEP
  entities
• Enable automatic representation of grove nodes as
  STEP entities
• Immediate goal full integration of engineering
  CAD/CAM/CAE data and hypermedia through
  HyTime/XLink
• Work progressing but not yet formally published
• Have established correspondence between the
  models
• Have modeled SGML and HyTime using EXPRESS
• Need to produce demonstration implementations and
  formalize results
• Done within ISO TC184/SC4 committee
• Contact W. Eliot Kimber, eliot_at_isogen.com

31
Resources

• HyTime Standardwww.hytime.org/papers/htguide.html
  ftp.ornl.gov/pub/sgml/wg8/document/n1920/html/n1
  920.html
• GROVES Papersxml.com/pub/2000/04/19/groves/index.
  htmlwww.hightext.com/IHC96/ek8.htmwww.prescod.ne
  t/groves/shorttut/www.oasis-open.org/cover/groves
  .htmlwww.techno.com
• Topic Map Standardwww.infoloom.com/tminfo.htm
  www.infoloom.com/tmsample/moo1.htm