WG3 – ProductdatabankenPieter Pauwels

29 november 2017

Outline

1. Recap op vorige status

2. Het ‘gemeenschappelijk’ datamodel en implementatie

3. Parallelle ontwikkelingen

4. Volgende stappen

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

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

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, …)

Gemeenschappelijk datamodel?

JSON REST API

Alt. Conv. Routines

Web App.

PDT

JSON REST API

JSON REST API

Outline

1. Recap op vorige status

2. Het ‘gemeenschappelijk’ datamodel en implementatie

3. Parallelle ontwikkelingen

4. Volgende stappen

Gemeenschappelijk datamodel?

JSON REST API

Alt. Conv. Routines

Web App.

PDT

JSON REST API

JSON REST API

https://hobby-gmpfaohcoeaggbkeodibkpol.dbs.graphenedb.com:24780/db/data/cypher

http://localhost:7474/db/data/cypher …

cypher query via HTTP POST

SQL querycypher query via HTTP POST

TechDat

SVK GUI Gyproc GUIHTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

Outline

1. Recap op vorige status

2. Het ‘gemeenschappelijk’ datamodel en implementatie

3. Parallelle ontwikkelingen

4. Volgende stappen

Product Data TemplatesCIBSE - coBuilder

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 2015.”

http://www.bimplus.co.uk/people/what-i-have-lear4nt-i-se8t-cobu6ilder-uk/

Performance Data

coBuilding Autodesk Revit plugin

BuildingSMART Int’l strategy

Fit in BuildingSMART activities

http://www.buildingsmart.org/standards/technical-vision/technical-roadmaps/29

Move towardsdata and web technologies

Official Community Groups

linkedbuildingdata.net

www.w3.org/community/lbd/

linkedbuildingdata community

LDAC event

ifcOWL

Key findings and contributions

1. Modularisation

2. Extensibility

3. Simplified access

31

W3C Strategy for building data

A number of key ontologies at W3C LBD

• Building Topology Ontology (BOT)

• Product Ontology (PRODUCT)

• Geometry Ontology (GEOM)

• Properties Ontology (PROPS)

modular

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

34extensible

Thomas Krijnen. http://aecgeeks.com/viewer/.simplified

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)

Outline

1. Recap op vorige status

2. Het ‘gemeenschappelijk’ datamodel en implementatie

3. Parallelle ontwikkelingen

4. Volgende stappen

JSON REST API

Alt. Conv. Routines

Web App.

PDT

JSON REST API

JSON REST API

https://hobby-gmpfaohcoeaggbkeodibkpol.dbs.graphenedb.com:24780/db/data/cypher

http://localhost:7474/db/data/cypher …

cypher query via HTTP POST

SQL querycypher query via HTTP POST

TechDat

SVK GUI Gyproc GUIHTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

HTTP GETGetProduct()GetSystem()

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, …)