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-90’s 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. SGML/XML/HTML Grove CGM Grove DB Schema Grove HyTime/Xlink Grove PDF Grove MS-Excel Grove API Grove “Style” Grove 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@isogen.com

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