Draft Recommendation Document
matthe...@informationjunction.co.uk
Dear Colleagues,
Having the Initial Review document now in its publication phase, it is time to draw on the work there to start work towards a recommendation. To that end I attach a draft recommendation document for your consideration. Comments are particularly welcome on:
- Are there any mistakes in approach or detail?
- Is there anything that needs better explanation?
- Are there key things that are missing?
Regards
Matthew West
Technical Lead – National Digital Twin programme
Steven Kraines
I have attached a somewhat heavily edited version of your
manuscript. As I have said to Chris, please take my edits
merely as suggestions for possible alternatives coming from
a newbie to the topic you are addressing. So please feel
free to zap/annihilate/disintegrate any edits that you do
not like/agree with.
I hope that this is helpful.
Best,
Steven
PS - I did not check the appendices.
On 2020/08/18 3:27, matthe...@informationjunction.co.uk wrote:
> Dear Colleagues,
>
> Having the Initial Review document now in its publication phase, it is
> time to draw on the work there to start work towards a recommendation.
> To that end I attach a draft recommendation document for your
> consideration. Comments are particularly welcome on:
>
> 2. Is there anything that needs better explanation?
> 3. Are there key things that are missing?
>
>
> Regards
>
> Matthew West
>
> Technical Lead – National Digital Twin programme
>
>
>
>
>
> 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
> <mailto:uk-ndt-fdm+...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/uk-ndt-fdm/003a01d674c4%240b2f9c90%24218ed5b0%24%40informationjunction.co.uk
> <https://groups.google.com/d/msgid/uk-ndt-fdm/003a01d674c4%240b2f9c90%24218ed5b0%24%40informationjunction.co.uk?utm_medium=email&utm_source=footer>.
matthe...@informationjunction.co.uk
Thanks for this. I notice the edits are almost entirely editorial, so I take it you think the general thrust is OK.
I will issue a new version of the document shortly (within 24 hours) making the cut on what to include in the master if others who have not started commenting want to wait for that.
Regards
Matthew West
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/01cd1e96-8143-4e0e-c501-8163d15f4ae4%40kraines.net.
Steven Kraines
Yes, the message is fine with me (honestly, I don't really
see myself in a position to say otherwise...). My only main
concern was in the clarity of the message.
(also, being American, I may just be unfamiliar with some
of the expressions you have used... :) ).
However, in the interest of being thorough, I was a bit
concerned about the following statements:
> Clearly for a National Digital Twin of the nation’s infrastructure we
will need a Top-Level Ontology rooted in the reality of science and
engineering.
I agree, I just wonder how clear this really is.
> The only way we can ensure that our unknown but expanding scope can be
accommodated is to set our scope as "life, the universe and everything,"
or to put it another way support anything valid that can be said.
This is actually related to the previous statement - surely we
can limit our scope (context?) to the reality of science and
engineering (do we really need to be able to talk about
flying pigs in Never Never Land)?
> Considering the detailed content of these four, it is soon clear that
each has some valuable features, and none encompasses all the features
desirable for our purposes with the Foundation Data Model. Equally the
four are sufficiently similar that bringing together the desirable
features of each into the Foundation Data Model seed is a relatively
straightforward task.
This statement sounds a bit too "convenient", but I guess
there is not enough space to elaborate on why while none
encompass all the features desirable for our purposes with
the Foundation Data Model, the combination of all four will.
Also, as I have noted in my comments, I would prefer to
remove usages of "entity" if possible to reduce potential
confusion. (regarding this, I did not complete the sentence
in the first paragraph of the section "implicit entities"
because I wasn't sure that "entities" was the right term there...)
Hoping that all of this is helpful.
Best,
Steven
Hugh Boyes
In the Appendix please would you add the following:
How do we address data aggregation where we want to provide aggregated information without revealing potentially sensitive underlying detailed data?
How do we address data aggregation where the combination of two or more models would reveal or facilitate disclosure of sensitive information?
The first of these questions would enable demand side modelling for a sub-station without allowing the consumption of individuals homes or business premises to be identified. The second question is applicable where assets or users (individuals) have been anonymised and enables the issue of reidentification to be addressed. There are potentially a range of aggregation by association and/or accumulation issues that will need to be considered, but these are appropriate placeholders for the purposes of this document.
Regards,
Hugh
——————————————
Hugh Boyes CEng FIET CISSP
Director
for and on behalf of Bodvoc Ltd
(M) 07970 703082
Cyber Essentials Plus Certificate Number CEP-4SE-09388
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.
Derwen Hinds FIET
Em. Tech. Futures
Honorary Principal Research Fellow, ISST, Imperial College
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/DD895EDB-B15B-46FE-B668-5C12F76A4319%40bodvoc.com.
Hugh Boyes
Thanks Derwen,
Yes I agree. Quantification is not an easy topic to address in groups like this, but certainly needs to be considered.
Regards,
Hugh
——————————————
Hugh Boyes CEng FIET CISSP
Director
for and on behalf of Bodvoc Ltd
(M) 07970 703082
Cyber Essentials Plus Certificate Number CEP-4SE-09388
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show
it to anyone. Please contact the sender if you believe you have received this email in error.
From: <uk-nd...@googlegroups.com> on behalf of Derwen Hinds FIET <dmh.f...@gmail.com>
Reply to: "uk-nd...@googlegroups.com" <uk-nd...@googlegroups.com>
Date: Tuesday, 18 August 2020 at 17:27
To: "uk-nd...@googlegroups.com" <uk-nd...@googlegroups.com>
Subject: Re: [FDM] Draft Recommendation Document
Hugh,
Valuable addition however, "sensitive" should be defined (maybe quantified?) as the readership may not fully understand the extent & types of sensitivity.
Examples of types of sensitivity could be 'commercial', 'financial', 'personal', 'identification', 'security (national, cyber & personal)' & 'safety' - any of which could lead to one or more outcomes of compromise, exploitation, deanonymisation (organisation, group or individual), disclosure, harm or damage.
Regards,
Derwen.
Derwen M. Hinds FIET
Independent Strategic Technical Advisor in Future and Emerging Technologies,
Em. Tech. Futures
Honorary Professor, STEaPP, UCL
Honorary Principal Research Fellow, ISST, Imperial College
Email: dmh.f...@gmail.com
Mobile: 07453 964 179
Sent from a Desktop Error! Filename not specified.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/uk-ndt-fdm/CABr_4ucG6p81QoUcaghtj%2BdCJfH2Tn8hmu_8EVLO56Up_NzGUQ%40mail.gmail.com.
matthe...@informationjunction.co.uk
I don't mean to be disobliging but...
Dear Matthew,
In the Appendix please would you add the following:
How do we address data aggregation where we want to provide aggregated information without revealing potentially sensitive underlying detailed data?
How do we address data aggregation where the combination of two or more models would reveal or facilitate disclosure of sensitive information?
The first of these questions would enable demand side modelling for a sub-station without allowing the consumption of individuals homes or business premises to be identified. The second question is applicable where assets or users (individuals) have been anonymised and enables the issue of reidentification to be addressed. There are potentially a range of aggregation by association and/or accumulation issues that will need to be considered, but these are appropriate placeholders for the purposes of this document.
Regards
Matthew West
Chris Partridge
Regards,
Chris Partridge
Chris Partridge |
Chief Ontologist | BORO Solutions Limited | www.BOROSolutions.co.uk
M: +44 790 5167263 | e: partr...@borogroup.co.uk
BORO Solutions Limited | Registered Office: 2 West Street, Henley on Thames, Oxfordshire RG9 2DU
Registered in England & Wales | Company No: 06025010 | VAT No. GB 905 6100 58
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/2E9E472D-0BC2-4ACF-895F-E19261DFBD25%40bodvoc.com.
matthe...@informationjunction.co.uk
Hi Matthew,
Yes, the message is fine with me (honestly, I don't really see myself in a position to say otherwise...).
My only main concern was in the clarity of the message.
(also, being American, I may just be unfamiliar with some of the expressions you have used... :) ).
However, in the interest of being thorough, I was a bit concerned about the following statements:
> Clearly for a National Digital Twin of the nation’s infrastructure we
will need a Top-Level Ontology rooted in the reality of science and engineering.
I agree, I just wonder how clear this really is.
> The only way we can ensure that our unknown but expanding scope can be
accommodated is to set our scope as "life, the universe and everything,"
or to put it another way support anything valid that can be said.
This is actually related to the previous statement - surely we can limit our scope (context?) to the reality of science and engineering (do we really need to be able to talk about flying pigs in Never Never Land)?
> Considering the detailed content of these four, it is soon clear that
each has some valuable features, and none encompasses all the features desirable for our purposes with the Foundation Data Model. Equally the four are sufficiently similar that bringing together the desirable features of each into the Foundation Data Model seed is a relatively straightforward task.
This statement sounds a bit too "convenient", but I guess there is not enough space to elaborate on why while none encompass all the features desirable for our purposes with the Foundation Data Model, the combination of all four will.
Also, as I have noted in my comments, I would prefer to remove usages of "entity" if possible to reduce potential confusion. (regarding this, I did not complete the sentence in the first paragraph of the section "implicit entities"
because I wasn't sure that "entities" was the right term there...)
Hoping that all of this is helpful.
Regards
Matthew
Andrew Mitchell
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/000401d67590%24dce73a50%2496b5aef0%24%40informationjunction.co.uk.
Andrew Mitchell | Ontologist | BORO Solutions Limited | www.BOROSolutions.net
Steven Kraines
Please see inline.
On 2020/08/19 3:53, matthe...@informationjunction.co.uk wrote:
> Yes, the message is fine with me (honestly, I don't really see myself in a position to say otherwise...).
> [MW] If not you then who?
project when I first contacted you 10-15 years ago about
digitalizing Tokyo.
(the "flagship paper was:
Steven B. Kraines, D.R. Wallace, Y. Iwafune, Y. Yoshida, T. Aramaki, K.
Kato, K. Hanaki, H. Ishitani, T. Matsuo, H. Takahashi, K. Yamada, K.
Yamaji, Y. Yanagisawa, H. Komiyama. An integrated computational
infrastructure for a virtual Tokyo: concepts and examples. Journal of
Industrial Ecology 5(1): 35-54.)
I have also done some with with BIM and IFC, so I might be able to
comment on the building aspect of your project. But it has been
10 years since I "got removed" from that area of work, so I am a
bit out of date....
>> Clearly for a National Digital Twin of the nation’s infrastructure we
> will need a Top-Level Ontology rooted in the reality of science and engineering.
>
> I agree, I just wonder how clear this really is.
> [MW] Do you think that needs further explanation then?
"Given the focus of NDT on the nation's infrastructure, we will
prefer a Top-Level Ontology that is rooted in the related domains
of ...."
>> The only way we can ensure that our unknown but expanding scope can be
> accommodated is to set our scope as "life, the universe and everything,"
> or to put it another way support anything valid that can be said.
>
> This is actually related to the previous statement - surely we can limit our scope (context?) to the reality of science and engineering (do we really need to be able to talk about flying pigs in Never Never Land)?
> [MW] That is an interesting question. Did you get the bit about formal generation? One thing we are almost certain to include in the FDM is Possible Worlds. This is a way of dealing with possibility. In engineering and business we need this in particular to deal with plans, which set out how you would like things to work out. Of course most plans turn out to be works of fiction. Now formal generation means that we get all possible worlds (I think they are uncountably infinite). This will include possible worlds in which pigs can fly. So now the question is whether that is harmless (we are not forced to be interested in any world where pigs fly) or whether we really need to eliminate the possibility of flying pigs from our ontology. It is probably possible, but likely to be quite complex and have unintended consequences. It is probably better to allow pigs to fly in their possible world and ignore them.
enterprise" in the Epistle Core Model. :)
I guess having pigs fly in Never Never Land might not be incompatible
with "the reality of science and engineering", but my tendency has been
to avoid claims for setting the scope to "everything" and do the best
I can to focus the scope on at least the general domain of interest.
Obviously if "limiting the scope" requires us to add complex and
difficult to understand mechanisms than it is fine to ignore the
flying pigs, but my understanding was that setting the scope to be
everything involves more difficult mechanisms in order to come up
with a data model that is actually useful (we *must* set our scope to
cover everything).
>> Considering the detailed content of these four, it is soon clear that
> each has some valuable features, and none encompasses all the features desirable for our purposes with the Foundation Data Model. Equally the four are sufficiently similar that bringing together the desirable features of each into the Foundation Data Model seed is a relatively straightforward task.
>
> This statement sounds a bit too "convenient", but I guess there is not enough space to elaborate on why while none encompass all the features desirable for our purposes with the Foundation Data Model, the combination of all four will.
> [MW] It does not say that drawing on all four is sufficient to create something that will meet our requirements. It only says there is useful material in each. I quite expect we will need to create some additional material as well.
misleading tone of the original statement.... :P
> Also, as I have noted in my comments, I would prefer to remove usages of "entity" if possible to reduce potential confusion. (regarding this, I did not complete the sentence in the first paragraph of the section "implicit entities"
> because I wasn't sure that "entities" was the right term there...)
> [MW] I went the other way, and removed references to objects.
using the term "objects" for describing the focus of TLOs?
Hugh Boyes
Hi Chris,
Whilst I accept Matthew’s point that there will be aspects of aggregation that are business process related. As such there is a need to be able to model sensitivity and where applicable any associated issues/concepts related to aggregation, confidentiality, etc.
For many organisations there is a requirement to for the capability to identify and protect valuable information assets and thus we need to have a common language to describe and design the business process to allow use of the data/information in specified ways. This is potentially a modelling requirement in all science and engineering disciplines as organisations and individuals seek to protect intellectual property, trade secrets and in medicine the confidentiality and/or anonymity of patient data. Our current challenge is the lack of a standardised way of describing the ‘classification’ of data and information, organisations use different terms/labels which makes sharing and reuse complex.
There is much work to do to get this right if the NDT concept is to operate in a security-minded way. The suggestion is simply to have a placeholder in the Appendix so that we acknowledge that this issue sits alongside questions related to versioning, ownership and the kinds of roles or actors.
Regards,
Hugh
——————————————
Hugh Boyes CEng FIET CISSP
Director
for and on behalf of Bodvoc Ltd
(M) 07970 703082
Cyber Essentials Plus Certificate Number CEP-4SE-09388
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show
it to anyone. Please contact the sender if you believe you have received this email in error.
From: <uk-nd...@googlegroups.com> on behalf of Chris Partridge <partr...@borogroup.co.uk>
Reply to: "uk-nd...@googlegroups.com" <uk-nd...@googlegroups.com>
Date: Tuesday, 18 August 2020 at 18:44
To: fdm ndt <uk-nd...@googlegroups.com>
Subject: Re: [FDM] Draft Recommendation Document
Hi Hugh,
Excellent point.
Matthew and I (and I think some others, maybe Al) discussed this requirement in the early stages.
The question I asked was whether we needed to include modelling of things like the sensitivity types and levels in the FDM itself. As you expect I/we have come across these requirements quite a few times, including issues about aggregation
One of the questions that always comes up is whether these types of issues should be relegated to a separate (standard?) model or included under the TLO in the FDM.
There are good arguments for both approaches - and no need to decide now. But useful to know there are options.
Regards,
Chris Partridge
To view this discussion on the web, visit
https://groups.google.com/d/msgid/uk-ndt-fdm/CA%2B8EkRpABeV7yCwT_jw%3DYA0U88m938UV-c6D_86y-cnos_mZUQ%40mail.gmail.com.
Chris Partridge
Regards,
Chris Partridge
Chris Partridge |
Chief Ontologist | BORO Solutions Limited | www.BOROSolutions.co.uk
M: +44 790 5167263 | e: partr...@borogroup.co.uk
BORO Solutions Limited | Registered Office: 2 West Street, Henley on Thames, Oxfordshire RG9 2DU
Registered in England & Wales | Company No: 06025010 | VAT No. GB 905 6100 58
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/C9188E6E-1077-4355-A2DA-8140B31B37BE%40bodvoc.com.
Derwen Hinds FIET
Sent from a Desktop
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/CA%2B8EkRrSnBFLPuf9rE4hTcP%2BqUDA9PQJVv_4FCE_ROO8dF9dsw%40mail.gmail.com.
Sergio De Cesare
Hi Matthew,
I think the document overall reads clearly and is well-structured. The rationale for adopting as seeds the four 4D ontologies mentioned is sound with a good explanation of the requirements and scope.
I attach the document with tracked changes mainly for a few typos found.
Just one question. In the document the distinction between real-world versus linguistic ontologies uses the terms foundational/linguistic. Is this terminological distinction found in the literature? I ask because DOLCE (an example of a TLO based on linguistics) is also referred to as a foundational ontology in the literature.
Regards,
Sergio
Andrew Mitchell | Ontologist | BORO Solutions Limited | www.BOROSolutions.net
M: +44 7596 267 310 | e: mitc...@borogroup.co.uk
BORO Solutions Limited | Registered Office: 2 West Street, Henley on Thames, Oxfordshire RG9 2DU
Registered in England & Wales | Company No: 06025010 | VAT No. GB 905 6100 58
--
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/CAF2%2Bs0WFbitAXoCXwXhuAHZdoX4rNMsNdd9UEo08va1wzUSWPw%40mail.gmail.com.
The University of Westminster is a charity and a company limited by guarantee. Registration number: 977818 England. Registered Office: 309 Regent Street, London W1B 2HW.
This message and its attachments are private and confidential. If you have received this message in error, please notify the sender and remove it and its attachments from your system.
matthe...@informationjunction.co.uk
Dear Andrew,
Thank you. I have had a quick look and there seems to be a pattern in the comments people are making, which is helpful.
I’m on holiday this week, so I will try to respond to the comments through an updated version starting work on it next week.
Regards
Matthew
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/CAF2%2Bs0WFbitAXoCXwXhuAHZdoX4rNMsNdd9UEo08va1wzUSWPw%40mail.gmail.com.
matthe...@informationjunction.co.uk
See responses [MW1]
> Yes, the message is fine with me (honestly, I don't really see myself in a position to say otherwise...).
> [MW] If not you then who?
Good question! You may recall that I was working on a similar project when I first contacted you 10-15 years ago about digitalizing Tokyo.
(the "flagship paper was:
Steven B. Kraines, D.R. Wallace, Y. Iwafune, Y. Yoshida, T. Aramaki, K.
Kato, K. Hanaki, H. Ishitani, T. Matsuo, H. Takahashi, K. Yamada, K.
Yamaji, Y. Yanagisawa, H. Komiyama. An integrated computational infrastructure for a virtual Tokyo: concepts and examples. Journal of Industrial Ecology 5(1): 35-54.)
I have also done some with with BIM and IFC, so I might be able to comment on the building aspect of your project. But it has been
10 years since I "got removed" from that area of work, so I am a bit out of date....
>> Clearly for a National Digital Twin of the nation’s infrastructure we
> will need a Top-Level Ontology rooted in the reality of science and engineering.
>
> I agree, I just wonder how clear this really is.
> [MW] Do you think that needs further explanation then?
I guess that I would phrase it something like "Given the focus of NDT on the nation's infrastructure, we will prefer a Top-Level Ontology that is rooted in the related domains of ...."
Perhaps this point needs better explanation.
>> The only way we can ensure that our unknown but expanding scope can
>> be
> accommodated is to set our scope as "life, the universe and everything,"
> or to put it another way support anything valid that can be said.
>
> This is actually related to the previous statement - surely we can limit our scope (context?) to the reality of science and engineering (do we really need to be able to talk about flying pigs in Never Never Land)?
> [MW] That is an interesting question. Did you get the bit about formal generation? One thing we are almost certain to include in the FDM is Possible Worlds. This is a way of dealing with possibility. In engineering and business we need this in particular to deal with plans, which set out how you would like things to work out. Of course most plans turn out to be works of fiction. Now formal generation means that we get all possible worlds (I think they are uncountably infinite). This will include possible worlds in which pigs can fly. So now the question is whether that is harmless (we are not forced to be interested in any world where pigs fly) or whether we really need to eliminate the possibility of flying pigs from our ontology. It is probably possible, but likely to be quite complex and have unintended consequences. It is probably better to allow pigs to fly in their possible world and ignore them.
Yes, I remember you giving the examples of "unicorn" and "the starship enterprise" in the Epistle Core Model. :) I guess having pigs fly in Never Never Land might not be incompatible with "the reality of science and engineering", but my tendency has been to avoid claims for setting the scope to "everything" and do the best I can to focus the scope on at least the general domain of interest.
Obviously if "limiting the scope" requires us to add complex and difficult to understand mechanisms than it is fine to ignore the flying pigs, but my understanding was that setting the scope to be everything involves more difficult mechanisms in order to come up with a data model that is actually useful (we *must* set our scope to cover everything).
>> Considering the detailed content of these four, it is soon clear that
> each has some valuable features, and none encompasses all the features desirable for our purposes with the Foundation Data Model. Equally the four are sufficiently similar that bringing together the desirable features of each into the Foundation Data Model seed is a relatively straightforward task.
>
> This statement sounds a bit too "convenient", but I guess there is not enough space to elaborate on why while none encompass all the features desirable for our purposes with the Foundation Data Model, the combination of all four will.
> [MW] It does not say that drawing on all four is sufficient to create something that will meet our requirements. It only says there is useful material in each. I quite expect we will need to create some additional material as well.
[MW1] Yes, I agree clarification would be helpful.
> Also, as I have noted in my comments, I would prefer to remove usages of "entity" if possible to reduce potential confusion. (regarding this, I did not complete the sentence in the first paragraph of the section "implicit entities"
> because I wasn't sure that "entities" was the right term there...)
> [MW] I went the other way, and removed references to objects.
Really! Interesting. After all that discussion with Chris about using the term "objects" for describing the focus of TLOs?
Regards
Matthew West
matthe...@informationjunction.co.uk
Dear Hugh,
Hi Chris,
Whilst I accept Matthew’s point that there will be aspects of aggregation that are business process related. As such there is a need to be able to model sensitivity and where applicable any associated issues/concepts related to aggregation, confidentiality, etc.
[MW] I agree.
For many organisations there is a requirement to for the capability to identify and protect valuable information assets and thus we need to have a common language to describe and design the business process to allow use of the data/information in specified ways. This is potentially a modelling requirement in all science and engineering disciplines as organisations and individuals seek to protect intellectual property, trade secrets and in medicine the confidentiality and/or anonymity of patient data. Our current challenge is the lack of a standardised way of describing the ‘classification’ of data and information, organisations use different terms/labels which makes sharing and reuse complex.
[MW] I also agree with this. It is just a matter of where it turns up.
There is much work to do to get this right if the NDT concept is to operate in a security-minded way. The suggestion is simply to have a placeholder in the Appendix so that we acknowledge that this issue sits alongside questions related to versioning, ownership and the kinds of roles or actors.
[MW] This is the key bit from the Pathway Document. The question I have for your is whether this is sufficient to cover what you are looking for?
Task 2B: Assessment of security threats and approaches
In this task, we will review security approaches, (considering PAS 185 and ISO 19650-5) and threat models. Although security-related information will be embodied throughout the resulting work, the security significance of the NDT means this will need to be considered upfront, and the results shared with those carrying out the remainder of the tasks, to ensure their awareness of the security context. Threat models will vary considerably depending on the types of application and digital twin involved.
In considering the security issues, it is necessary to look beyond the traditional concepts of confidentiality, integrity and availability to assess and understand the implications in respect of:
• authenticity – is the data/information being used of known and acceptable provenance and how can this be verified?
• utility – the asset will change over its life cycle, through maintenance or replacement or components or augmentation to change its capability or capacity. How will one establish that the historic telemetry data is comparable and consistent with that currently being used, and if not, how are long term trends monitored and managed?
• safety – what effect do changes to the physical and digital elements of the twin have on the safety case for the asset, its use or outputs?
• resilience – of the digital twin, how will it transform, renew and/or recover, in a timely manner in response to adverse events?
• control – will access to the digital twin enable unauthorised control or modification of the physical asset, or enable hostile reconnaissance?
• sensitive information – how will the infrastructure prevent transfer and release of personally identifiable and commercially sensitive information, and how will the intellectual property of twins be protected?
We will be required to handle situations where a query requires access to data that the user is not authorised to use.
We must consider how to respond to an authorisation failure in circumstances where it would be inappropriate to inform the user of the authorisation failure, as this would acknowledge the presence of information that they are not authorised to access: proposals on how to respond to this challenge should be made here. (For example, one common choice is to return the “wrong” error code, returning “not found” where the “correct” response is “forbidden”.)
Deliverable: A limited distribution paper discussing the threat modelling and security architecture of the proposed approach.
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/C9188E6E-1077-4355-A2DA-8140B31B37BE%40bodvoc.com.
Hugh Boyes
Dear Matthew,
Task 2B as drafted covers the generic set of security issues that we will need to address at single model level. Whilst it does not explicitly address the question of aggregation, that is a consideration that a model designer/developer should take into account and may be delivered thought varying levels of access and display.
What I think is missing from Task 2B is the handling of the data aggregation arising from assimilation, processing and display of data from multiple models. In this scenario we could be faced by two or more models, which when viewed or used in isolation do not result in any increased risk, as the designers/owners have taken into account the potential damage or harm. However, the combination of data which in isolation may have seemed relatively innocuous but results in patterns or enable deductions that are or could if misused be harmful. To model and write business rules to mitigate such combinations I foresee the need for the TLO to incorporate entities that provide a basis for a mechanism that can limit access/use on a context sensitive basis, e.g. when combining data sets that facilitate the reidentification of anonymised assets, persons, etc. This problem is not addressed by the Task 2B text regarding sensitive information.
To answer your question – no 2B is not sufficient given aggregation issues we are currently seeking to address.
Regards,
Hugh
——————————————
Hugh Boyes CEng FIET CISSP
Director
for and on behalf of Bodvoc Ltd
To view this discussion on the web, visit
https://groups.google.com/d/msgid/uk-ndt-fdm/014201d676d2%2473e86c70%245bb94550%24%40informationjunction.co.uk.
matthe...@informationjunction.co.uk
Dear Sergio,
Thank you for this review. As with other comments I’ll try to look at them next week.
See below.
Hi Matthew,
I think the document overall reads clearly and is well-structured. The rationale for adopting as seeds the four 4D ontologies mentioned is sound with a good explanation of the requirements and scope.
I attach the document with tracked changes mainly for a few typos found.
Just one question. In the document the distinction between real-world versus linguistic ontologies uses the terms foundational/linguistic. Is this terminological distinction found in the literature? I ask because DOLCE (an example of a TLO based on linguistics) is also referred to as a foundational ontology in the literature.
[MW] That is one for Chris I think (it is his classification that makes it not foundational). Of course one of the problems is that just because we use a term with a particular meaning, does not mean others are required to do the same. I hope I was clear what we mean here by foundational.
Here is just one place where it is described as Foundational:
http://www.loa.istc.cnr.it/dolce/overview.html
and this:
Foundational choices in DOLCE Stefano Borgo Claudio Masolo February 20, 2008
“DOLCE, the Descriptive Ontology for Linguistic and Cognitive Engineering [15], is a foundational ontology…”
Regards
Matthew West
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/C020AA6B-D7E1-4DDF-9020-875427FBA8EF%40westminster.ac.uk.
matthe...@informationjunction.co.uk
Dear Hugh,
Thanks for this more detailed analysis.
Task 2B as drafted covers the generic set of security issues that we will need to address at single model level. Whilst it does not explicitly address the question of aggregation, that is a consideration that a model designer/developer should take into account and may be delivered thought varying levels of access and display.
[MW] OK. Well that is something at least.
What I think is missing from Task 2B is the handling of the data aggregation arising from assimilation, processing and display of data from multiple models. In this scenario we could be faced by two or more models, which when viewed or used in isolation do not result in any increased risk, as the designers/owners have taken into account the potential damage or harm. However, the combination of data which in isolation may have seemed relatively innocuous but results in patterns or enable deductions that are or could if misused be harmful. To model and write business rules to mitigate such combinations I foresee the need for the TLO to incorporate entities that provide a basis for a mechanism that can limit access/use on a context sensitive basis, e.g. when combining data sets that facilitate the reidentification of anonymised assets, persons, etc. This problem is not addressed by the Task 2B text regarding sensitive information.
[MW] I’m struggling to see how this is going to work. How do you expect to prevent two data sets being used together? What would stop me from getting one of them myself, and the other through a friend or colleague, and then putting them together. I expect I could prevent both of them being used together within the NDT, but what is to stop them being taken separately outside the NDT and then used together?
It seems to me that the only way to be truly sure of not being able to deduce patterns is to make sure that the level of aggregation is sufficient that there is not another data set that could make a significant impact on privacy in combination.
To answer your question – no 2B is not sufficient given aggregation issues we are currently seeking to address.
[MW] OK. But how do you think you can make data sets available at all and prevent their use in combination (especially since the underlying idea behind the NDT is to make data sets available for use together so you can learn more from combining them.
Regards
Matthew
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/87701F1F-10C2-4D81-A816-5FDF79374690%40bodvoc.com.
Chris Partridge
Regards,
Chris Partridge
Chris Partridge |
Chief Ontologist | BORO Solutions Limited | www.BOROSolutions.co.uk
M: +44 790 5167263 | e: partr...@borogroup.co.uk
BORO Solutions Limited | Registered Office: 2 West Street, Henley on Thames, Oxfordshire RG9 2DU
Registered in England & Wales | Company No: 06025010 | VAT No. GB 905 6100 58
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/000c01d67728%24657c2400%2430746c00%24%40informationjunction.co.uk.
Steven Kraines
Please see inline... SBK1
On 2020/08/20 18:10, matthe...@informationjunction.co.uk wrote:
> Dear Steven,
> See responses [MW1]
>
>> Yes, the message is fine with me (honestly, I don't really see myself in a position to say otherwise...).
>> [MW] If not you then who?
> Good question! You may recall that I was working on a similar project when I first contacted you 10-15 years ago about digitalizing Tokyo.
> (the "flagship paper was:
> Steven B. Kraines, D.R. Wallace, Y. Iwafune, Y. Yoshida, T. Aramaki, K.
> Kato, K. Hanaki, H. Ishitani, T. Matsuo, H. Takahashi, K. Yamada, K.
> Yamaji, Y. Yanagisawa, H. Komiyama. An integrated computational infrastructure for a virtual Tokyo: concepts and examples. Journal of Industrial Ecology 5(1): 35-54.)
>
> I have also done some with with BIM and IFC, so I might be able to comment on the building aspect of your project. But it has been
> 10 years since I "got removed" from that area of work, so I am a bit out of date....
> [MW1] It seems to me you are getting up to speed quickly.
>>> Clearly for a National Digital Twin of the nation’s infrastructure we
>> will need a Top-Level Ontology rooted in the reality of science and engineering.
>>
>> I agree, I just wonder how clear this really is.
>> [MW] Do you think that needs further explanation then?
>
> I guess that I would phrase it something like "Given the focus of NDT on the nation's infrastructure, we will prefer a Top-Level Ontology that is rooted in the related domains of ...."
> [MW1] That is specifically something we are not trying to do. What you just described is a bottom up approach - start with the detail and work your way up to more general stuff. We are specifically trying to start at the top and say that these a fundamentally the kinds of thing you can have (out of some choices of which sorts of things one can choose to have). The reason for this is to achieve consistency across some different (and expanding) domains we wish to address.
[SBK1] What I do believe even in the face of your
[SBK1] arguments is that still a sincere effort
[SBK1] should (must?) be made to identify at least
[SBK1] broadly what domains must be included in
[SBK1] the scope. But as you observed below, I
[SBK1] have a different idea about what is involved
[SBK1] in modeling "life, the universe and everything". ;)
> Perhaps this point needs better explanation.
[SBK1] if he or she does, I am afraid you would need
[SBK1] a lot more explanation... :(
>>> The only way we can ensure that our unknown but expanding scope can
>>> be
>> accommodated is to set our scope as "life, the universe and everything,"
>> or to put it another way support anything valid that can be said.
>>
>> This is actually related to the previous statement - surely we can limit our scope (context?) to the reality of science and engineering (do we really need to be able to talk about flying pigs in Never Never Land)?
>> [MW] That is an interesting question. Did you get the bit about formal generation? One thing we are almost certain to include in the FDM is Possible Worlds. This is a way of dealing with possibility. In engineering and business we need this in particular to deal with plans, which set out how you would like things to work out. Of course most plans turn out to be works of fiction. Now formal generation means that we get all possible worlds (I think they are uncountably infinite). This will include possible worlds in which pigs can fly. So now the question is whether that is harmless (we are not forced to be interested in any world where pigs fly) or whether we really need to eliminate the possibility of flying pigs from our ontology. It is probably possible, but likely to be quite complex and have unintended consequences. It is probably better to allow pigs to fly in their possible world and ignore them.
>
> Yes, I remember you giving the examples of "unicorn" and "the starship enterprise" in the Epistle Core Model. :) I guess having pigs fly in Never Never Land might not be incompatible with "the reality of science and engineering", but my tendency has been to avoid claims for setting the scope to "everything" and do the best I can to focus the scope on at least the general domain of interest.
> Obviously if "limiting the scope" requires us to add complex and difficult to understand mechanisms than it is fine to ignore the flying pigs, but my understanding was that setting the scope to be everything involves more difficult mechanisms in order to come up with a data model that is actually useful (we *must* set our scope to cover everything).
> [MW1] Actually, it turns out that the hardest bit of setting your scope as "everything" is deciding that is what you want. By and large it all gets easier once you have made that decision (compared to the alternatives) and you start doing different things. A clarification that is necessary is that it is the ambition to support a scope of everything, there might always be shortcomings, and Chris has mentioned some of these. That clarification should be made in the document.
[SBK1] I am still not convinced. Something to do with seeing
[SBK1] so many in AI get burned for selling silver bullets...
>>> Considering the detailed content of these four, it is soon clear that
>> each has some valuable features, and none encompasses all the features desirable for our purposes with the Foundation Data Model. Equally the four are sufficiently similar that bringing together the desirable features of each into the Foundation Data Model seed is a relatively straightforward task.
>>
>> This statement sounds a bit too "convenient", but I guess there is not enough space to elaborate on why while none encompass all the features desirable for our purposes with the Foundation Data Model, the combination of all four will.
>> [MW] It does not say that drawing on all four is sufficient to create something that will meet our requirements. It only says there is useful material in each. I quite expect we will need to create some additional material as well.
>
> Aha. I missed that. Still - that points out the somewhat misleading tone of the original statement.... 😝
> [MW1] Yes, I agree clarification would be helpful.
>
>> Also, as I have noted in my comments, I would prefer to remove usages of "entity" if possible to reduce potential confusion. (regarding this, I did not complete the sentence in the first paragraph of the section "implicit entities"
>> because I wasn't sure that "entities" was the right term there...)
>> [MW] I went the other way, and removed references to objects.
>
> Really! Interesting. After all that discussion with Chris about using the term "objects" for describing the focus of TLOs?
> [MW1] Different document for a largely different audience. I noted that you found "object" initially confusing. That is not helpful. Our audience for the Recommendation will include people like Government Chief Scientific Advisors who will not be familiar (or about to become familiar) with the philosophical niceties and are therefore likely to have a similar experience.
[SBK1] in my word choice ;) ).
[SBK1] Your readers will almost certainly be damn much less familiar
[SBK1] with the philosophical niceties
[SBK1] (at least I read your book! :P ).
Hugh Boyes
Dear Matthew,
I am conscious that you have a specific task to complete and don’t wish to divert attention from completing the recommendation paper. The detail of how we might solve the problem is something we can address once the recommendation is accepted and the FDM development work is funded. It is likely to include specific measures will be required in all of the components shown in your Figure 1, as well as business process and governance arrangements for the deployment and operation of models as part of the NDT. Your point about data sets being extracted and shared is well made, but that is an information security issue that we already have to address through policies, security operating procedures, user training and ultimately disciplinary/legal action.
Regarding your point about making data sets available to all – that is unlikely to be acceptable on a number of grounds. The experience we are gaining from some currently live projects demonstrates that asset owners/operators have legitimate concerns about access to some of their data. To address these concerns and others regarding security, sensitivity, intellectual property, etc. the discovery protocol and authorisation layer will have to accommodate varying levels of visibility of and access to models and data.
An acknowledgement in the Appendix that there are questions to be addressed regarding the aggregation of data would suffice at this stage of the programme, we can work on the detail once your recommendation has been accepted.
Regards,
Hugh
——————————————
Hugh Boyes CEng FIET CISSP
Director
for and on behalf of Bodvoc Ltd
(M) 07970 703082
Cyber Essentials Plus Certificate Number CEP-4SE-09388
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show
it to anyone. Please contact the sender if you believe you have received this email in error.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/uk-ndt-fdm/000c01d67728%24657c2400%2430746c00%24%40informationjunction.co.uk.
Hugh Boyes
Hi Chris,
Yes the use of markings is likely to be part of the solution, hence the suggestion that the TLO needs to accommodate data that represents security, sensitivity and/or handling restrictions.
As I have just suggested in my response to Matthew we do not need to solve it now, just have a suitable reference in the recommendation document that allows us to refer back to the issue during subsequent design and development.
Regards,
Hugh
——————————————
Hugh Boyes CEng FIET CISSP
Director
for and on behalf of Bodvoc Ltd
(M) 07970 703082
Cyber Essentials Plus Certificate Number CEP-4SE-09388
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show
it to anyone. Please contact the sender if you believe you have received this email in error.
From: <uk-nd...@googlegroups.com> on behalf of Chris Partridge <partr...@borogroup.co.uk>
Reply to: "uk-nd...@googlegroups.com" <uk-nd...@googlegroups.com>
Date: Friday, 21 August 2020 at 00:01
To: fdm ndt <uk-nd...@googlegroups.com>
Subject: Re: [FDM] Draft Recommendation Document
Hi Matthew,
I think what is envisaged is that data would get markings. And when the certain data (of whatever type) is aggregated, then there is a process for determining the new markings. Of course, the worrying case is where the aggregated data is more sensitive, but presumably there would be cases when it would be less sensitive.
Your point about people getting the datasets and aggregating for themselves is well made.
However, I think this is just part of a more general issue. This is how markers like sensitivity and provenance are handled when mapping to the FDM formats. While the FDM may only consume the transformed data - it might be worth sensitising
people who are doing the mapping (including any aggregation) to the concern.
Regards,
Chris Partridge
Regards,
Chris PartridgeError! Filename not specified.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/uk-ndt-fdm/CA%2B8EkRq%3DfL-UqFXfKp4DDmDH4nJ9vfDo__7BpmpXhR%3DMo4SqYQ%40mail.gmail.com.
Chris Partridge
[SBK1] arguments is that still a sincere effort
[SBK1] should (must?) be made to identify at least
[SBK1] broadly what domains must be included in
[SBK1] the scope. But as you observed below, I
[SBK1] have a different idea about what is involved
[SBK1] in modeling "life, the universe and everything". ;)
Regards,
Chris Partridge
Chris Partridge |
Chief Ontologist | BORO Solutions Limited | www.BOROSolutions.co.uk
M: +44 790 5167263 | e: partr...@borogroup.co.uk
BORO Solutions Limited | Registered Office: 2 West Street, Henley on Thames, Oxfordshire RG9 2DU
Registered in England & Wales | Company No: 06025010 | VAT No. GB 905 6100 58
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/92d7ea8d-690f-8ffb-6680-a51fb96a5d57%40kraines.net.
Steven Kraines
Are you familiar with the idea of domain models
(e.g. in the context of domain-driven design and
also the stuff by Martin Fowler and associates...)?
From my understanding, one of the key tasks is to
define the scope of the domain to be modeled.
Would be most grateful for any thoughts / comments
you have in this regard.
Best,
Steven
> <mailto:partr...@borogroup.co.uk>
> BORO Solutions Limited | Registered Office: 2 West Street, Henley on
> Thames, Oxfordshire RG9 2DU
> Registered in England & Wales | Company No: 06025010 | VAT No. GB 905
> 6100 58
>
>
>
> On Fri, 21 Aug 2020 at 03:09, Steven Kraines <ste...@kraines.net
> <mailto:ste...@kraines.net>> wrote:
>
> Hi Matthew,
>
> Please see inline... SBK1
>
> On 2020/08/20 18:10, matthe...@informationjunction.co.uk
> >>>> Dear Colleagues,
> >>>>
> >>>> Having the Initial Review document now in its publication
> phase, it
> >>>> is time to draw on the work there to start work towards a
> recommendation.
> >>>> To that end I attach a draft recommendation document for your
> >>>> consideration. Comments are particularly welcome on:
> >>>>
> >>>> 1. Are there any mistakes in approach or detail?
> >>>> 2. Is there anything that needs better explanation?
> >>>> 3. Are there key things that are missing?
> >>>>
> >>>>
> >>>>
> >>>> Regards
> >>>>
> >>>> Matthew West
> >>>>
> >>>> Technical Lead – National Digital Twin programme
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>>> <mailto:uk-ndt-fdm+...@googlegroups.com
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>>.
> >>>>
> https://groups.google.com/d/msgid/uk-ndt-fdm/003a01d674c4%240b2f9c90
> >>>> %
> >>>> 2 4218ed5b0%24%40informationjunction.co.uk
> <https://groups.google.com/d/msgid/uk-ndt-fdm/003a01d674c4%240b2f9c90%24218ed5b0%24%40informationjunction.co.uk?utm_medium=email&utm_source=footer>.
> >>>
> >>> --
> >>> 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
> >>>
> >>
> >> --
> >> 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
> >>
> >
> > --
> > 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
> >
>
> --
> 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
> --
> 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
> <mailto:uk-ndt-fdm+...@googlegroups.com>.
> To view this discussion on the web, visit
> <https://groups.google.com/d/msgid/uk-ndt-fdm/CA%2B8EkRq%2Bd7%3D1Zsf5RWcLvXVKptWCwdqFigk0HAWYHUw92yUnug%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Al
I just spotted your mention of Martin Fowler. Matthew and I noticed a
great article on Martin's website not long ago:
https://martinfowler.com/articles/data-monolith-to-mesh.html
I wrote the email to Matthew and Mark Enzer at the time. See copy
below. I think this is a sign that stalwarts of Enterprise Architecture
are realising that there is a lot more to data consistency and modelling
than they had presviously tried to nail down within a "domain". The
article is a good read even if it hasn't yet recognised that ontology is
necessary. We should really be able to contribute a lot to this community.
Al
----------- Copy of email sent to Matthew & Mark a couple of months ago
---------------------------
Hi Matthew,
I saw this article not long after it came out last year. Perhaps I
should have forwarded it...
Martin Fowler is a figure of some standing in the Enterprise Software
Application world and is likely to be worth taking some notice of
(although he didn't author the article). I like the style of the
article and I am always pleased when people take the time to write more
than just a superficial account of what they want to say. Some reactions:
- I agee with the high level diagnosis of current architectures. The
author rightly identifies that many (most) current generation systems
are 'centralised' behind the scenes, even if there is a mask of cloud
provision and microservices that makes it look to a technical audience
like a (potentially, but not actually) dynamic system.
- The sentence "We have moved away from domain oriented data ownership
to a centralized domain agnostic data ownership." sums it up well. For
those who care about data quality & what is represented by the data, the
result is that data quality is typically reduced to the lowst common
denominator of the 'lightweight', big data-compatible, centralised model
- which is almost no model at all in some cases. The better ones just
use appending of tags that indicate something about the data in the
centralised repository. This, at least, can have some benefits if it is
done well but it doesn't make for consistent data outside of the realms
of the 'metadata' or 'tags'. This is how the Gene Ontology is currently
used, I believe.
- The paragraph after Figure 5 is superb. I've copied it here and won't
add anything more. "I personally don't envy the life of a data platform
engineer. They need to consume data from teams who have no incentive in
providing meaningful, truthful and correct data. They have very little
understanding of the source domains that generate the data and lack the
domain expertise in their teams. They need to provide data for a diverse
set of needs, operational or analytical, without a clear understanding
of the application of the data and access to the consuming domain's
experts."
- Making data the product. I like the way that the data mesh is
described and the summary of the properties you'd expect from such a
[software] architecture shift. In the limit, I don't think it will work
as well as they think without addressing information quality across the
system in the way that we are advising for DBB. They can still get
benefits but they will be far more limited than they think. Much of
what they suggest is going towards your original IML, Matthew, by
addressing things that were not typically addressed by the more
monolithic style of development (like requirements change, domain
ownership, trust, interoperability standards, etc). It may be worth
having a direct chat with Martin about this once we are advanced a bit
further.
- Some of what is said in the "self-describing semantics" and
"inter-operable [] global standards" is waffle (i.e. well intended but
just way more limiting than the words suggest).
One Martin's own pages about software quality is also worth reading:
https://martinfowler.com/articles/is-quality-worth-cost.html
I have seen people start to recognise this in some of the organisations
I work with but they are still in the minority. I will claim that the
prototype system that I have implemented based on Matthew's HQDM data
model is an example (at small scale) that delivers approximately
everything in the data mesh vision (with some rough edges!). Technology
isn't the limitation.
Thanks for sending it around.
Al
Chris Partridge
> (e.g. in the context of domain-driven design and
> also the stuff by Martin Fowler and associates...)?
> From my understanding, one of the key tasks is to
> define the scope of the domain to be modeled.
Regards,
Chris Partridge
Chris Partridge |
Chief Ontologist | BORO Solutions Limited | www.BOROSolutions.co.uk
BORO Solutions Limited | Registered Office: 2 West Street, Henley on Thames, Oxfordshire RG9 2DU
Registered in England & Wales | Company No: 06025010 | VAT No. GB 905 6100 58
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/38d63740-8ed3-91b1-c3e9-4b2d5f18ce2a%40criticalinsight.co.uk.
Steven Kraines
Wow - it truly is a small world!!! :)
Honestly, I am not completely convinced by the
arguments set forth by Evans and Fowler. One
of the reasons I asked about them... ;)
I do like the idea of using context maps to
define context boundaries, and focusing on carefully
defining and controlling the subset of the overall
domain model (I guess he calls this a shared kernel).
This is the approach we have been taking at ASAM.
Steven
> >>
> >> BORO Solutions Limited | Registered Office: 2 West Street, Henley on
> >> Thames, Oxfordshire RG9 2DU
> >> Registered in England & Wales | Company No: 06025010 | VAT No. GB 905
> >> 6100 58
> >>
> >>
> >>
> >> On Fri, 21 Aug 2020 at 03:09, Steven Kraines <ste...@kraines.net
> <mailto:ste...@kraines.net>
> >>
> >> Hi Matthew,
> >>
> >> Please see inline... SBK1
> >>
> >> On 2020/08/20 18:10, matthe...@informationjunction.co.uk
> <mailto:matthe...@informationjunction.co.uk>
> >> >>> Dear Steven,
> >> >>> Thanks for this. I notice the edits are almost entirely
> >> editorial, so I take it you think the general thrust is OK.
> >> >>> I will issue a new version of the document shortly
> (within 24
> >> hours) making the cut on what to include in the master if
> others who
> >> have not started commenting want to wait for that.
> >> >>> Regards
> >> >>> Matthew West
> >> >>>
> >> >>> -----Original Message-----
> >> >>> From: uk-nd...@googlegroups.com
> <mailto:uk-nd...@googlegroups.com>
> >> <mailto:uk-nd...@googlegroups.com
> <mailto:uk-nd...@googlegroups.com>> <uk-nd...@googlegroups.com
> <mailto:uk-nd...@googlegroups.com>
> >> <mailto:uk-nd...@googlegroups.com
> <mailto:uk-nd...@googlegroups.com>>> On
> >> >>> Behalf Of Steven Kraines
> >> >>> Sent: 18 August 2020 07:56
> >> >>> To: uk-nd...@googlegroups.com
> <mailto:uk-nd...@googlegroups.com>
> >> >>> Subject: Re: [FDM] Draft Recommendation Document
> >> >>>
> >> >>> Hi Matthew,
> >> >>>
> >> >>> I have attached a somewhat heavily edited version of your
> >> manuscript. As I have said to Chris, please take my edits
> merely as
> >> suggestions for possible alternatives coming from a newbie
> to the
> >> topic you are addressing. So please feel free to
> >> zap/annihilate/disintegrate any edits that you do not
> like/agree with.
> >> >>>
> >> >>> I hope that this is helpful.
> >> >>>
> >> >>> Best,
> >> >>>
> >> >>> Steven
> >> >>>
> >> >>> PS - I did not check the appendices.
> >> >>>
> >> >>>
> >> >>> On 2020/08/18 3:27,
> matthe...@informationjunction.co.uk
> <mailto:matthe...@informationjunction.co.uk>
> >> >>>> Dear Colleagues,
> >> >>>>
> >> >>>> Having the Initial Review document now in its publication
> >> phase, it
> >> >>>> is time to draw on the work there to start work towards a
> >> recommendation.
> >> >>>> To that end I attach a draft recommendation document
> for your
> >> >>>> consideration. Comments are particularly welcome on:
> >> >>>>
> >> >>>> 1. Are there any mistakes in approach or detail?
> >> >>>> 2. Is there anything that needs better explanation?
> >> >>>> 3. Are there key things that are missing?
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Regards
> >> >>>>
> >> >>>> Matthew West
> >> >>>>
> >> >>>> Technical Lead – National Digital Twin programme
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> 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
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>
> <mailto:uk-ndt-fdm%252Buns...@googlegroups.com>>
> >> >>>> <mailto:uk-ndt-fdm+...@googlegroups.com
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>
> >> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com
> <mailto:uk-ndt-fdm%252Buns...@googlegroups.com>>>.
> >> >>>>
> >>
> https://groups.google.com/d/msgid/uk-ndt-fdm/003a01d674c4%240b2f9c90
> >> >>>> %
> >> >>>> 2 4218ed5b0%24%40informationjunction.co.uk
> <http://40informationjunction.co.uk>
> >> <http://40informationjunction.co.uk>
> >> >>>>
> >>
> <https://groups.google.com/d/msgid/uk-ndt-fdm/003a01d674c4%240b2f9c90%24218ed5b0%24%40informationjunction.co.uk?utm_medium=email&utm_source=footer>.
> >> >>>
> >> >>> --
> >> >>> 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
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>
> <mailto:uk-ndt-fdm%252Buns...@googlegroups.com>>.
> >>
> https://groups.google.com/d/msgid/uk-ndt-fdm/01cd1e96-8143-4e0e-c501-8163d15f4ae4%40kraines.net.
> >> >>>
> >> >>
> >> >> --
> >> >> 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
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>
> <mailto:uk-ndt-fdm%252Buns...@googlegroups.com>>.
> >>
> https://groups.google.com/d/msgid/uk-ndt-fdm/d6e09848-7617-af85-175f-8354016a37d3%40kraines.net.
> >> >>
> >> >
> >> > --
> >> > 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
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>
> <mailto:uk-ndt-fdm%252Buns...@googlegroups.com>>.
> >>
> https://groups.google.com/d/msgid/uk-ndt-fdm/a497e6fd-ccbb-c39c-4868-ee00139fb231%40kraines.net.
> >> >
> >>
> >> --
> >> You received this message because you are subscribed to the
> >> 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
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>
> <mailto:uk-ndt-fdm%252Buns...@googlegroups.com>>.
> >>
> https://groups.google.com/d/msgid/uk-ndt-fdm/92d7ea8d-690f-8ffb-6680-a51fb96a5d57%40kraines.net.
> >>
> >> --
> >> 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
> >> <mailto:uk-ndt-fdm+...@googlegroups.com
> <mailto:uk-ndt-fdm%2Bunsu...@googlegroups.com>>.
> >> To view this discussion on the web, visit
> >>
> >>
> <https://groups.google.com/d/msgid/uk-ndt-fdm/CA%2B8EkRq%2Bd7%3D1Zsf5RWcLvXVKptWCwdqFigk0HAWYHUw92yUnug%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> 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,
> https://groups.google.com/d/msgid/uk-ndt-fdm/38d63740-8ed3-91b1-c3e9-4b2d5f18ce2a%40criticalinsight.co.uk.
> --
> 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
> <mailto:uk-ndt-fdm+...@googlegroups.com>.
> To view this discussion on the web, visit
> <https://groups.google.com/d/msgid/uk-ndt-fdm/CA%2B8EkRo973PV0R2qPxF7%3DmoGKkB%2B%2BaZ2_KdxH5bBsg3nLQsPhA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
matthe...@informationjunction.co.uk
Dear Hugh,
There are really two separate points here:
- Do we need to recognise information requirements for security? (Yes)
- Is aggregation (or other techniques to protect sensitive data) effective if combining data sets can reveal sensitive data (I’m doubtful).
I am conscious that you have a specific task to complete and don’t wish to divert attention from completing the recommendation paper.
[MW] We need to take the time to get it right (as far as possible).
The detail of how we might solve the problem is something we can address once the recommendation is accepted and the FDM development work is funded.
[MW] Agreed.
It is likely to include specific measures will be required in all of the components shown in your Figure 1, as well as business process and governance arrangements for the deployment and operation of models as part of the NDT. Your point about data sets being extracted and shared is well made, but that is an information security issue that we already have to address through policies, security operating procedures, user training and ultimately disciplinary/legal action.
[MW] I agree. This works fine for data not made publicly available, but if it is not publicly available I wonder about the value of obscuring sensitive data in the first place since you have other effective controls, and the data is likely to be more useful with more detail available.
Regarding your point about making data sets available to all – that is unlikely to be acceptable on a number of grounds.
[MW] I’m sure there will be some data that is publicly available, even if it is only tube maps, road networks, train punctuality etc. The point is that such data must be such that it cannot be combined to reveal sensitive data. On the other hand, if it is not public, and access is controlled, I don’t see the point in obscuring sensitive data.
The experience we are gaining from some currently live projects demonstrates that asset owners/operators have legitimate concerns about access to some of their data.
[MW] Yes. That is recognised in the structure of the integration architecture already. We need to pick up the data requirements that implies. The appendix you refer to wanting an addition is supposed to be requirements from the Pathway document, so I am just trying to work out whether what you are talking about can be considered as part of that, or whether I have to restructure the appendix to include requirements that the Pathway document missed.
To address these concerns and others regarding security, sensitivity, intellectual property, etc. the discovery protocol and authorisation layer will have to accommodate varying levels of visibility of and access to models and data.
[MW] I think that is already in the Pathway document, so we just need to fish it out and add it. If it is there I will do it, if not add it as implicit requirements.
An acknowledgement in the Appendix that there are questions to be addressed regarding the aggregation of data would suffice at this stage of the programme, we can work on the detail once your recommendation has been accepted.
[MW] That would be new, and additional to the requirements stated/implicit in the Pathway document, which is why I am questioning whether there is any substance there. As far as I can see if a data set was capable of revealing sensitive information in conjunction with another data set, though neither alone would reveal it, then it has to be treated as if it did reveal it (this could be tricky to determine with data sets from different organizations). However, in the end it seems to me it is still just a matter of how you classify the sensitivity of information (together with the procedures for handling information with that sensitivity), which we will have to do anyway.
Thanks for sticking with this.
Regards
Matthew West
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/76B4F065-6F4D-440F-B1C8-A6EEEBE0CD38%40bodvoc.com.
matthe...@informationjunction.co.uk
Dear Chris,
I thought I had covered this.
I do have one niggle with Matthew's formulation - the use of say. Natural language is really flexible. The grammar does not stop us saying that is a round square or two plus two equals six. Also, even when what we say is not obviously inconsistent, we often have not worked out how to formalise it - and formalise it in a way that is consistent with the rest of the model. So, I'd suggest caveating 'said' - with 'provided we formalise it'.
[MW] The document says “say anything that is valid". The “valid” is supposed to cover your point.
Regards
Matthew
To view this discussion on the web, visit https://groups.google.com/d/msgid/uk-ndt-fdm/CA%2B8EkRq%2Bd7%3D1Zsf5RWcLvXVKptWCwdqFigk0HAWYHUw92yUnug%40mail.gmail.com.