Managing Shared Data

23 views
Skip to first unread message

matthe...@informationjunction.co.uk

unread,
Feb 1, 2022, 6:03:59 AM2/1/22
to UK-NDT-FDM

Dear Colleagues,

Apologies for the long radio silence, but most of what we do takes quite a while. So I’m pleased to attach a copy of a draft of Managing Shared Data, which is now being sent into the publication process at CPNI.

This document builds on and updates “The Pathway towards an Information Management Framework” published by CDBB nearly two years ago now.

Regards

Matthew West

 

Dr Matthew West OBE
Technical Lead – National Digital Twin programme
https://www.cdbb.cam.ac.uk/what-we-do/national-digital-twin-programme

 

image001.png
image002.jpg
MSD vfinal for publication.pdf

Ian Cornwell

unread,
Feb 7, 2022, 5:12:03 AM2/7/22
to UK NDT FDM
There's a lot of wisdom in that document.
One additional concept that I believe is useful would be to recognise the role of pre-existing established industry models in influencing the adopted models and ontology, which can be done in a systematic way such as through the core components harmonisation process described in ISO TR 25100:2012. (I admit that specific harmonisation approach has never become firmly established, but then no systematic approach to bottom-up harmonisation has, and there hasn't been as much progress on data model and ontology harmonisation as there might have been.)

matthe...@informationjunction.co.uk

unread,
Feb 7, 2022, 8:58:00 AM2/7/22
to uk-nd...@googlegroups.com

Dear Ian,

I thought I had set out what we are doing in this area, but just to reiterate.

 

  1. We definitely expect a role for Industry Data Models and Reference Data Libraries, and more particularly data based on them. However, they are also part of the problem in that they are incompatible with each other.
  2. Some of what it takes to achieve compatibility is just data model/ontology improvement. Doing the ontological analysis to identify what is being talked about and what the rules are for those things. Sometimes incompatibility arises because one group talks about what another group talks about in a more constrained way than generally applies.
  3. Sometimes you find there are different names for the same thing. Probably the easiest thing to do is just recognise that is the case and make names for things part of your ontology.
  4. Sometimes you get the same name for slightly different things. An example for this is that in the early days, different countries used different definitions of what a COVID death was (possibly still the case). This makes it difficult to compare data. Here you need to agree a definition and get people to agree to use it. This really is harmonization (and probably standardisation).

I hope that helps.

Regards

Matthew

--
You received this message because you are subscribed to the Google Groups "UK NDT FDM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uk-ndt-fdm+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/baa5130b-7d52-47a7-8907-e9357c7d52afn%40googlegroups.com.

Ian Cornwell

unread,
Feb 7, 2022, 10:11:56 AM2/7/22
to UK NDT FDM
Thanks Matthew. I totally agree that your 4 points should happen in development of ontologies and models, and that existing models present problems. I like to recognise that explicitly with a process, where semantically overlapping models are analysed to yield common ontology without the specific contexts of the original models and harmonised models that are context-specific and more concrete instances. But I admit most harmonisation activity doesn't follow that process explicitly and rigorously, it tries to achieve the same harmonisation results by relying on the participants to work out what concessions to harmonisation they can make by peer-to-peer comparisons or ad-hoc methods. Re-reading the section on "Industry Data Models" I agree it is already clear that this envisages this kind of harmonisation (sorry if I implied that it didn't), and I think our viewpoints are close on this. Consider my mention of core components harmonisation as one suggestion about how the analysis and harmonisation of existing data models can proceed. In the terminology used by the document, it should identify "facets" and their relationship and the contextual factors that cause the diversification.
Aside - I used the phrase "bottom up" in my post, but I should be careful about that in this conversation because of the (excellent) visualisation of the seven circles - in which "bottom up" would mean the opposite - I meant from existing artefacts to harmonised artefacts. 

matthe...@informationjunction.co.uk

unread,
Feb 11, 2022, 3:26:11 AM2/11/22
to uk-nd...@googlegroups.com

Dear Ian,

I agree we are talking in a very similar way.

Just one thing I want to clarify here. Your email reads as if the integration analysis is done at the data model level. In practice we start with the data, and look for the ontological patterns there. We treat the data model then as just more data that goes into the mix.

Regards

Matthew

 

Dr Matthew West OBE
Technical Lead – National Digital Twin programme
https://www.cdbb.cam.ac.uk/what-we-do/national-digital-twin-programme

 

 

 

image001.png
image002.jpg

Ian Cornwell

unread,
Feb 11, 2022, 4:07:18 AM2/11/22
to uk-nd...@googlegroups.com

Matthew,

“we start with the data” – interesting! In harmonisation across different communities or systems, normally the things I can access are the data models rather than any actual data, so it has been practical to use the data models.

 

“integration analysis” – the context in which I’ve worked on harmonisation across data models was a different one to building a single integrated system – it was aiming at harmonisation of data specifications where there is no immediate plan to integrate in one specific system, but where those specifications are part of one interconnected domain so that it is likely there will be integration in future, and also likely that there will be scope for the same engineers working in the domain to access both forms of data and potentially use common building blocks. The lack of a specific integration instance or specific data source instances may partly explain the focus on data models rather than data.

 

Regards,

Ian Cornwell

Technical Principal

+44(0)141 222 4576     

ian.co...@mottmac.com

--
You received this message because you are subscribed to a topic in the Google Groups "UK NDT FDM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/uk-ndt-fdm/9Y7iDyma2VA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to uk-ndt-fdm+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/00d001d81f20%24fe4b6c80%24fae24580%24%40informationjunction.co.uk.

Reply all
Reply to author
Forward
0 new messages