WG3 Productdatabanken. Pieter Pauwels 29 november 2017

Transcriptie

1 WG3 Productdatabanken Pieter Pauwels 29 november 2017

2 Outline 1. Recap op vorige status 2. Het gemeenschappelijk datamodel en implementatie 3. Parallelle ontwikkelingen 4. Volgende stappen

3 Recap op vorige status (6 oktober) Bedrijfsbezoeken Onderzoeksproject VLAIO Inladen van productdata en bevraagbaar maken Bezorgdheid over producten (raamprofielen) versus systemen (ramen) Bezorgdheid over positie ten opzicht van bestaande commerciële systemen (waarom een extra portaal) Implementatietraject voor bedrijven volgens drie alternatieve pistes

4 Bevindingen (1) Regelmatig een onderscheid terug te vinden tussen producten en systemen (van producten). Producten zijn typisch beschikbaar in eindige lijsten, met eveneens een eindige lijst van eigenschappen. Systemen komen voor in oneindig veel vormen, afhankelijk van de configuratie door de klant. Het lijkt doenbaar om een databank op te maken van producten, maar veel minder evident om een databank van systemen te maken. Deze systemen zijn eerder éénmalige oplossingen. Een verkoper wil zelden zo n overzicht ter beschikking stellen. Er wordt eerder getracht om sets of lijnen van systemen aan te bevelen, waarvan de eigenschappen intervallen zijn (tussen 20 en 40mm). Dergelijke intervallen zijn dan weer moeilijk te vatten in een databank, en die resultaten zijn weinig bruikbaar voor de eindklant (geen exacte prestatie-eigenschappen, noch exacte berekeningen).

5 Bevindingen (2) Groot deel van de markt lijkt met Excel te werken voor het beheer van productdata Heel klein deel van de markt heeft eigen databank en content management system van waaruit vrij gemakkelijk gekoppeld zou kunnen worden van buitenaf. Bijgevolg: ongestructureerde aanpak primeert. Sterk risico op onbetrouwbare data (typfouten, ingevoerde kolommen & rijen, )

6

7 Gemeenschappelijk datamodel?

8

9

10 JSON REST API JSON REST API PDT JSON REST API Alt. Conv. Routines Web App.

11 Outline 1. Recap op vorige status 2. Het gemeenschappelijk datamodel en implementatie 3. Parallelle ontwikkelingen 4. Volgende stappen

12 Gemeenschappelijk datamodel?

13 JSON REST API JSON REST API PDT JSON REST API Alt. Conv. Routines Web App.

14 HTTP GET GetProduct() GetSystem() TechDat HTTP GET GetProduct() GetSystem() HTTP GET GetProduct() GetSystem() SVK GUI HTTP GET GetProduct() GetSystem() Gyproc GUI HTTP GET GetProduct() GetSystem() cypher query via HTTP POST cypher query via HTTP POST SQL query nedb.com:24780/db/data/cypher

15 Outline 1. Recap op vorige status 2. Het gemeenschappelijk datamodel en implementatie 3. Parallelle ontwikkelingen 4. Volgende stappen

16 Product Data Templates CIBSE - cobuilder

17

18

19

20 Nick Tune about PDTs But when it comes to the type and format of data to share there has been confusion as to whose Product Data Templates defining the format/properties of the data that you should share are the right ones to use. PDTs have been produced by NBS and CIBSE, and many organisations have developed their own versions of them. In my view, there will never be a perfect PDT as each client will have their own data requirements and their own language needs. For example, a client may only want four specific product properties and they may want them in German and in IFC. Another client will want 10 properties and will need them in English and in COBie and Revit. Therefore, in my view the starting point for naming and defining a product s properties such as wind resistance or thermal transmittance should always be the relevant European and British standards, including Declarations of Performance, Environmental Performance Declarations, or Safety Data Sheets. For the names of products themselves, the starting point should be Uniclass

21

22

23

24

25 Performance Data

26 cobuilding Autodesk Revit plugin

27

28 BuildingSMART Int l strategy

29 Fit in BuildingSMART activities Move towards data and web technologies 29

30 Official Community Groups linkedbuildingdata.net ifcowl LDAC event linkedbuildingdata community

31 Key findings and contributions 1. Modularisation 2. Extensibility 3. Simplified access 31

32 W3C Strategy for building data

33 A number of key ontologies at W3C LBD Building Topology Ontology (BOT) Product Ontology (PRODUCT) Geometry Ontology (GEOM) Properties Ontology (PROPS) modular

34 extensible Jakob Beetz, Michelle Lindlar, Stefan Dietze, Ujwal Gadiraju, Dag Field Edvardsen, Lars Bjørkhaug, Ontological 34 Framework for a Semantic Digital Archive. DuraArk Deliverable D3.3.2.

35 simplified Thomas Krijnen.

36 A number of key ontologies at W3C LBD Building Topology Ontology (BOT) Product Ontology (PRODUCT) Geometry Ontology (GEOM) Properties Ontology (PROPS) Industry Foundation Classes (ifcowl)

37

38 Outline 1. Recap op vorige status 2. Het gemeenschappelijk datamodel en implementatie 3. Parallelle ontwikkelingen 4. Volgende stappen

39 JSON REST API JSON REST API PDT JSON REST API Alt. Conv. Routines Web App.

40 HTTP GET GetProduct() GetSystem() TechDat HTTP GET GetProduct() GetSystem() HTTP GET GetProduct() GetSystem() SVK GUI HTTP GET GetProduct() GetSystem() Gyproc GUI HTTP GET GetProduct() GetSystem() cypher query via HTTP POST cypher query via HTTP POST SQL query nedb.com:24780/db/data/cypher

41 Volgende stappen 1. Combineren van gemeenschappelijk datamodel, PDTs, W3C Product ontology, IFC PSETs 2. Onderzoek aanmaak van systemen vs. producten 3. Web-interface bouwen op databank 4. Softwarebedrijven laten communiceren met APIs zodat ze dit met hun geometrie kunnen combineren 5. Databank exporteren / migreren naar alternatieven databanksystemen (graphdb naar SQL, )