View
214
Download
0
Embed Size (px)
Citation preview
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