1. DesKs: Design Knowledge Servers Jos van Leeuwen & Sverker Fridqvist

2. A Feature? What’s that?? Confusion with Form Features Even when explained, not a convincing term, too narrowly interpreted So, new terminology, same ideas: Feature TypesFeature Instances ConceptsIndividuals

3. Concepts A slight simplification of the notion as compared to Feature Types A Concept is an object-class that defines a general design idea Concepts define such an idea by: –Specifying what type of value it can have –Specifying its relationships to other concepts (and individuals)

4. Concepts Concept Type of value string, integer, boolean, … Relationships decomposition, associations, …

5. Individuals An Individual is an object that represents a part of a particular design Individuals represent designs by: –Having a particular value –Having relationships to other individuals Individuals are based on Concepts, but can extend Concepts (by adding relationships)

6. Individuals Individual Value “Kitchen”, 42, true, … Relationships parts, connections, … Concept Type of value string, integer, boolean, … Relationships decomposition, associations, …

7. Example of a concept definition Material string Width real (mm) Height real (mm) Thickness real (mm) Wall R-value real Colour

8. Example of a concept with fixed properties Width real (mm) Height real (mm) Thickness real (mm) Prefab Interior Wall R-value real Grey Composite Material 2600mm max height

9. Schema evolution: designers shape their own tools Concise modelling of design rationale Formalization of design knowledge A means to express (new) typologies for design concepts products, materials, construction methods Prospectives Norman Foster Cranfield University Library

10. Layered modelling Distributed ownership and responsibility of part-models Prospectives (cont.)

11. Design Knowledge and Design Models How to organise and exchange? Organisation –Document vs. model –Dead or alive, consistency, up-to-date information –Data storage models Communication –Push vs. pull (send vs. request) Ownership and access control Contractual responsibility, legal issues

12. Design Knowledge and Design Models Norms Product info Design

13. Design Knowledge and Design Models K+M design model Remote data integration

14. Design Knowledge and Design Models Storage of Concepts and Individuals (read: Knowledge and Models) Organisation using Namespaces Authenticated and authorised access control to remote data K+M

15. Namespaces Containers for identifiers of data (types) Are themselves globally uniquely identifiable (often by using a URL) Are supported by standard technology (XML) and thus will live for a while

16. Remote data access Data stays where it is No documents or data-objects are exchanged Controlled access –Users, Groups, and Authors –Access levels –Pay-per-view Distributed data = distributed responsibilities Instant updates Dynamic data: process behind e.g. special pricing, design analysis and evaluation, …

17. Example architect a beam manufacturer IPE200 length height 200mm length 6.2m engineer a structure evaluation

18. Implementation: Design Knowledge Servers (DesKs) DesKsCore Data management software, an API for building a variety of applications DesKsNode Prototype application, graphical Windows interface DesKsWebserver (planned) Webserver application with form-based interface

19. Aspects of DesKsCore (1) Using Namespaces –Both Concepts and Individuals in a namespace –Nesting namespaces? –Distributing namespaces? –How to find namespaces? URL’s? –Users and Groups in namespaces? –Versions of namespaces?

20. Aspects of DesKsCore (2) Multiple inheritance e.g. a wall is both a structural element and a space separating element –Facilitates the Concept Recognition process (previously called Feature Type Recognition) –But how to deal with e.g. overriding? Implicit overriding of properties or explicit only? –How to deal with conflicts? How far should we go to protect users against their own stupidity? Or do things get too complex for users to oversee?

21. Aspects of DesKsCore (3) Versioning –Major and minor versions per object –Revisions during editing (before publication) –Timeline management: ability to save a time-slot 1.0 2.0 1.1 2.2 time conceptproperties versions 2.0 named time-slot

22. Aspects of DesKsCore (4) Authentication and Authorisation Checkout mechanism for editing purposes –Remote editing –Submitting revisions (not for publication) –Committing versions (for publication) –Two modes of editing: realtime editing (e.g. drag to move) non-realtime editing (e.g. click to move) –Multi-user editing

23. Aspects of DesKsCore (5) Persistence Storage is implemented using an RDBS (SQL-server) Exchange and interfacing XML import and export Prepare future support for XML integration e.g. intelligent product description pages on the web Remote access Using.NET Remoting (HTTP + SOAP)

24. User management Namespaces, Concepts, & Individuals Graphical Editor Object Editor Object Browser Component relationships Components DesKsNode application Group ownership Authenticated access

25. Some conclusions DesKs addresses a set of internationally recognised issues: Flexible and extensible schema’s Model-based data management Web-based data management Knowledge representation and case-based reasoning Data-ownership issues Information-on-demand principle

26. Some more conclusions DesKs has potentials to be successful for: Supply chain in the construction sector –Providing product information in a smart format –Integration of product information in the design process Collaborative design –Remote collaboration –Development of multi-user environments

27. Final conclusions Parametric Geometry issues need to be addressed (help needed!) Incorporation/application of DesKs in other projects is desirable: usable release required in short term… Valuable theoretical outcome