1. Knowledge Management at 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. Groves Are Uniform! SGML/XML/HTML Grove CGM Grove PDF Grove MS-Excel Grove API Grove DB Schema Grove HyTime/Xlink Grove “Style” Grove

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 Standard www.hytime.org/papers/htguide.html ftp.ornl.gov/pub/sgml/wg8/document/n1920/html/n1920.html  GROVES Papers xml.com/pub/2000/04/19/groves/index.html www.hightext.com/IHC96/ek8.htm www.prescod.net/groves/shorttut/ www.oasis-open.org/cover/groves.html www.techno.com  Topic Map Standard www.infoloom.com/tminfo.htm www.infoloom.com/tmsample/moo1.htm