WP1 data-model

In this page we can keep track of the discussion about the data model for WP1. We have collected all the relevant emails and documents that have been sent to the different people involved in this task because often the emails have not been sent to all the recipients.

Mail 1

Dear Martin,
I was forwarded your e-mail about Data Model by Paolo. I here attach a suggested template for the final deliverable (part of the larger D1.3). We think it's important to focus a bit on existing Data Model for shoes and then to start shaping our product-factory Data Model. This is to be done according to the needs pointed out by Scenarios. The attached file provides a template and an example. looking forward to your feedback.
Best Regards,
Ilario


Attach

Mail 2

Dear Paolo, dear Ilario, dear Giovanni,
as promised, we send you here the preliminary version of the “DOROTHY Factory Data Model”.
This document includes a short information about factory data models and similar to Ilario´s Data Model Template some examples of factory data models.
Please take it only as an answer to your previous emails and again, as a preliminary and internal version of the factory data model, only for us. Pease do not distribute it while again, it was conceived only for us, the partners involved into the Task 1.2.
The goal of Task 1.2 is to identify main data objects, attributes, functions, relationships and interfaces. Now we are researching a detailed plan, how to achieve this goal.
Best regards
Martin and IFF team


Attach

Mail 3

Hello Paolo!
Please find attached description of what is STEP standard all about. I hope this will help you understand my wish to use standards in DOROTHY project.
Best regards
Jurij Franko
Alpina d.d.


Attach

Mail 4

Hello Jurij,
Thanks again for hosting the meeting, and for the mail.
I include in the discussion all the other people working on the data model: Carmen, Martin, Ilario, Giovanni;
We were not capable to find an already defined Application Protocol that fits our needs, do you have any suggestions in this regard? (I'm referring to the product: shoe. There is something in terms of Factory Planning)
The development of a STEP compliant AP is a huge work (for example the definition of the AP 224 "Mechanical product definition for process planning using machining feature" is more then 1000 pages!) that is outside the scope of Dorothy with few benefits for the partners (unless you want to promote it, as an ISO standard).
We suggest to use UML (that is an ISO standard as well) that is more agile and widely adopted in the software industry to define data models. UML is then far better know by the partners and better supported by development tools (As far as I know)
maybe I misunderstood you purpose… because the mail was short… thus please let me know
wishes
Paolo

Mail 5

Hello Paolo!

I have briefly studied ULM, STEP, EXPRESS and combining with my own experience with IGES, VDA-FS and other geometry formats, and working as independent consultant in CAD for more than 15 years, I can give my view on the subject in more detail.

There are many data to be moved between different subjects involved in product (shoe) design, development, production, distribution and sales. As far as I understand, Dorothy should produce one kind of data model for our branch. There are many questions connected to this subject, but I will start with:

How and where our business and our product differs from other businesses like tooling, aeroplane, automotive ? Can we relate to their problems, their needs and their solutions? Can we learn, copy, ‘steel’ from them? Or should we reinvent the wheel (or just part of it) ?

There are two types of data, we should consider in our business model:

1. Product related
2. Transaction related

If I just think about Product related data, they fall into two categories:
- geometry data (curves, surfaces, relations between them, dimensions, tolerances…)
- non geometry data (colors, physical properties, chemical properties, coatings, quality parametrs, production data…)
On the other side Transaction related data are more or less equal to any
other business and answers the most simple questions:

- what
- where
- when
- how much (money, quantity…)

If Dorothy will follow ‘Design Of customeR dRiven shOes and multi-siTe factorY’ as stated in the name of the project, by definition all data listed above should be included in shoe data model to fulfill the mission statement.

Therefore I believe that using STEP and EDIFACT as standards, we can ‘copy and paste’ at least some of the solutions already developed for our purposes like:

1. geometry data
2. part of non geometry data
3. much of Transaction related data

As our business is also relating to other businesses like tool making, chemistry, transport, the information flow to those is also vital and could lead to considerable savings in the process. Use of standards developed for product definition will also paved the road to automatic data transfer between them much better then proprietary data model developed specially for our business.

None of the project members is from anglo-speaking world, but we have all chosen English language as the most appropriate (but by any mean not perfect) mean of communication within this project, because it is understood and spoken by all parties involved. None of us is perfect in English, but sufficiently good to communicate and we improve with time. We did not invent our own language for the project J. In STEP, many of questions and problems waiting for us in developing data model are already solved or have close enough solutions for the problems, we will face. I agree that STEP is huge document, but my question is why? Because they are paid per page? I do not believe that. I know that Product related data are so complex that we at this point of Dorothy have not scrached the surface yet.

Regarding ULM.

By definition this is:

The OMG specification states:

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."

From: http://www.sparxsystems.com.au/uml-tutorial.html

As far as I can understand, this definition is close to definition of EXPRESS-G and EXPRESS – part of STEP – and can be used in the same way regarding data model.

If you read http://en.wikipedia.org/wiki/ISO_10303 it states:

Typically STEP can be used to exchange data between CAD, Computer-aided manufacturing, Computer-aided engineering, Product Data Management/EDM and other CAx systems. STEP is addressing product data from mechanical and electrical design, Geometric dimensioning and tolerancing, analysis
and manufacturing, with additional information specific to various industries such as automotive, aerospace, building construction, ship, oil and gas, process plants and others.

As I understand it Dorothy job can be just adding industry specific information into STEP. As STEP as any other data model is not static, I believe that Dorothy will succeed if it will start the initiative and
develop first draft to show benefits to the industry, then the industry itself should put pressure on SW vendors to move forward with STEP level 3 implication.

There are many examples from history and current praxis of use of international standards (including my wife using EDIFACT in her own very small business) for the benefit of all involved and sometimes there are
unexpected synergies discovered and exploited. I expect that by using standard for product definition, cooperation between different suppliers (materials, parts, SW…) in our business will increase and also new
suppliers will enter the business.

Best regards

Jurij

Mail 6

Dear Giovanni
What about publishing the attached Word-File (as a zip-file with the password) and the mail underneath on the wiki-site (http://dorothy.wikidot.com/wp1-datamodel)?

It is inline with Paolo’s UML document and shows the
- possible connection of all data throughout the value chain
- possibility to consider knowledge throughout the value chain

In detail:
We exploited the UML structure in the initial document (data model template). We just specified in front of the customer
- Foot scan
- Gender (male / female)
- Application (Formal, High fashion, sport)
Instead of
- Foot scan
- Select Aesthetics
- Select Materials

The three applications (Formal, High fashion, sport) are derived from Boers book and those three axes…
Our idea is that the customer has demands which have to be mapped to the technical view on the shoe. Thus we enlarged your example with our ideas concerning that customer centric point of view. Thus, in addition to your class diagram, we added a class diagram containing the initial customer data. Furthermore, the introduced CCMS-approach is than mapping the Customer-Point-Of-View on the technical items using matrices.

We where analyzing the following two dimensions (Cognitive Dimension & Value Chain Dimension):

1. Cognitive Dimension

1.1. Data

1.2. Information

1.3. Knowledge
-> How do we exploit the available data in the data model when applying our knowledge? As an example:

1.1. Data
-> Attributes in the class diagram

1.2. Information
-> The class diagram itself providing the context of the data. Like: "Shoe" consists of "Upper" and "Sole".

1.3. Knowledge
-> Rules in the matrices of the CCMS-approach, linking the information. Like: there is no “cocktail shoe” available for “male persons”.

2. Value Chain Dimension in the context of cluster 2

2.1. Customer

2.2. Local or internet shop

2.3. Factory, …
-> Customer-centric data mining for the data model. What data is implied by the customer buying shoes? What is the impact on the data and the data model following our 2 scenarios (BFS & MCO) throughout the entire value chain starting at the customer? The result is the data to be managed in both data models (shoe & factory).
Best regards,
Jens, Noelle & Anders


Attach