DesKs: Design Knowledge Servers Jos van Leeuwen & Sverker Fridqvist

DesKs: Design Knowledge ServersDesKs: Design Knowledge Servers

Jos van Leeuwen & Sverker Fridqvist

A Feature? What’s that??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 Types Feature Instances

Concepts Individuals

ConceptsConcepts

• 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)

ConceptsConcepts

Concept Type of valuestring, integer, boolean, …

Relationshipsdecomposition, associations, …

IndividualsIndividuals

• 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)

IndividualsIndividuals

Individual Value“Kitchen”, 42, true, …

Relationshipsparts, connections, …

Concept Type of valuestring, integer, boolean, …

Relationshipsdecomposition, associations, …

Example of a concept definitionExample of a concept definition

Materialstring

Widthreal (mm)

Heightreal (mm)

Thicknessreal (mm)

Wall R-valuereal

Colour

Example of a concept with fixed propertiesExample of a concept with fixed properties

Widthreal (mm)

Heightreal (mm)

Thicknessreal (mm)

PrefabInterior

WallR-value

real

Grey

CompositeMaterial

2600mm

maxheight

• Schema evolution:designers shapetheir own tools

• Concise modellingof design rationale

• Formalization ofdesign knowledge

• A means to express(new) typologiesfor design conceptsproducts, materials, construction methods

ProspectivesProspectives Norman FosterCranfield University

Library

• Layered modelling

• Distributed ownership and responsibility of part-models

Prospectives (cont.)Prospectives (cont.)

Design Knowledge and Design ModelsDesign 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

Design Knowledge and Design ModelsDesign Knowledge and Design Models

Norms

Norms

Productinfo

Productinfo

Design

Design Knowledge and Design ModelsDesign Knowledge and Design Models

K+M

K+MK+M

K+M

design model

Remote data integration

Design Knowledge and Design ModelsDesign 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

NamespacesNamespaces

• 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

Remote data accessRemote data access

• Data stays where it isNo 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, …

ExampleExample

architecta beam

manufacturerIPE200

length

height

200mm

length

6.2m

engineera structure

evaluation

Implementation:Design Knowledge Servers (DesKs)Implementation:Design Knowledge Servers (DesKs)

• DesKsCoreData management software, an API for building a variety of applications

• DesKsNodePrototype application, graphical Windows interface

• DesKsWebserver (planned)

Webserver application with form-based interface

Aspects of DesKsCore (1)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?

Aspects of DesKsCore (2)Aspects of DesKsCore (2)

• Multiple inheritancee.g. a wall is both a structural element and aspace 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?

Aspects of DesKsCore (3)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

1.01.0

1.0

2.01.1

2.2

time

concept properties

versions

2.0named time-slot

Aspects of DesKsCore (4)Aspects of DesKsCore (4)

• Authentication and AuthorisationCheckout 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

Aspects of DesKsCore (5)Aspects of DesKsCore (5)

• PersistenceStorage is implemented using an RDBS (SQL-server)

• Exchange and interfacingXML import and export

• Prepare future support for XML integratione.g. intelligent product description pages on the web

• Remote accessUsing .NET Remoting (HTTP + SOAP)

User managemen

t

Namespaces, Concepts, & Individuals

GraphicalEditor

ObjectEditor

ObjectBrowser

Component relationships

Components

DesKsNode applicationDesKsNode application

Group ownership

Authenticated access

Some conclusionsSome 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

Some more conclusionsSome 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

Final conclusionsFinal 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