knowledge management at the datum level n.
Skip this Video
Loading SlideShow in 5 Seconds..
Knowledge Management at the Datum Level PowerPoint Presentation
Download Presentation
Knowledge Management at the Datum Level

Knowledge Management at the Datum Level

150 Vues Download Presentation
Télécharger la présentation

Knowledge Management at the Datum Level

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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,

  31. Resources • HyTime • GROVES • Topic Map