Feel free to add any comments to this page!!


  • The document talks about "Data Sources" in a title, but then continues to use "datasources" as one word. I tried to look up what the correct spelling is, but both appear online and not in a dictionary. The title seems more correct. But we should at least be consistent.


  • The section on Actuators is confusing. "An actuator is a component of a machine that is responsible for moving and controlling a mechanism or system, for example by opening a valve." (src: https://en.wikipedia.org/wiki/Actuator).
    • Tanguy: I've changed the text to read the way that actuators are to be understood in the text. It now reads "Actuators are here to be understood as non-human elements that can effect a change in the real-world.". I hope this clarifies things.
    • JanWillem: Thanks, perfect!
    • But part of the text is about an autonomous agent. It also says that actuators require automated decision making to function. That is untrue: when I press the unlock button of my car fob, the doors are unlocked by actuators.
    • Tanguy: the text does not speak of agents. In addition, it recognizes that not all actuators need an autonomous decision making process, where we the example of the light turning on and of is described.
    • JanWillem: I meant this part: "Actuators require automated (as opposed to human) decision making to function."


  • bi-directional communication
    • Jorre: I have changed the definition paragraph of UDT's with more focus on what bi-directional communication exactly means. Any thoughts on that?
    • Tanguy: I like it, Thx!


  • Definition Urban Digital Twin:
    • Jorre: Ik denk dat we hier moet focussen op de kenmerken waar volgens ons absoluut moeten aan voldaan zijn. Nu blijft het nog vaag met de definitie van Tao et al. Voor mij is dat
      1. Constante/longitudinale data-verzameling. Zo kunnen evoluties en causale verbanden onderzocht worden. De tijdsintervallen hoeven niet kort te zijn (real-time) maar kunnen ook langere perioden bevatten, bv. jaarcijfers. Zolang er maar herhaalde metingen zijn.
      2. Een onderliggend data model die alle informatie bronnen in relatie brengt, eventueel zelfs met causale relaties.
      3. Een regelmatige automatische update van het data model bij nieuwe binnenkomende informatie.
      4. Een feedbackmechanisme dat informatie uit de digital twin terugkoppelt naar de physieke wereld en de physieke wereld aanstuurt. Dat kan automatisch of via menselijke beslissingen en ingrepen. Dit mechanisme moet leiden tot aanpassingen in de physieke wereld die ook automatisch gecapteerd kunnen worden door de digital twin.
    • Jorre: Wat valt er niet onder deze definitie: de GUI,...
    • Tanguy: Ik heb de voorkeur voor een simpele definitie dat een complexe definitie. Akkoord dat dit zaken zijn dit belangrijk zijn in een DT, maar als we dit verankeren in de definitie komen we in discussies over wat wel en geen UDT, wat denk ik niet altijd even productief is. In deel over "marturity levels" heb ik getracht om een onderscheid te maken tussen verschillende soorten UDT.


  • Typologie
    • Jorre: Interessant onderzoek zou zijn om de typologie verder scherp te stellen en dan de use cases classificeren volgend die typologie. Dit kan in beperkte groep experten, die elk onafhankelijk de classificatie maken waarna alles vergeleken wordt. Ik zou bv. geen onderscheid maken tussen support horizon want dat zit ook al ingebed in de support phase. Ook de end-user lijkt me minder relevant voor de Digital Twin zelf, enkel voor de User Interface is dat belangrijk, maar de UI is voor mij geen inherent deel van een digital twin zelf.
    • Tanguy: akkoord dat dit interessant onderzoek zou zijn en een mogelijke piste om op te nemen indien we deze paper willen omzetten naar een academische publicatie.
    • --GertDegreef (overleg) 15 apr 2021 10:04 (CEST): de typologie moet inderdaad nog eens worden uitgediept: met name de use cases zijn nu enkel wat we 'organisch' hebben zien ontstaan vanuit een aantal prio's, maar kan niet als 'typologie' dienen, daarvoor is het niet gestructureerd genoeg (want waarom niet vb 'stress' of 'drukte' dan vermelden). Anderzijds vind ik het weldegelijk juist om de de horizon en user types mee te nemen.


  • Data Sources
    • --GertDegreef (overleg) 15 apr 2021 10:04 (CEST): I'm not fond of the 'static' word. In other presentations we use "fast moving and slow moving data" instead of "dynamic and static data". Thoughts?


  • Models:
    • Jorre: add causal models, goal is to go from process-centric to data-centric models
    • Tanguy: Not sure what you mean by a causal model. Bother process and data centric are causal, I would argue.


  • Air Quality and traffic:
    • JanWillem: Two sentences start with "As a result" just one after the other. Should be rephrased.
    • Tanguy: THx


  • I think some of the texts are a bit long to digest. Could it make sense to use a tool like grammarly to break up long sentences?
  • Tanguy: feel free to do so.

--Philippecarlo (overleg) 29 mrt 2021 16:02 (CEST)

Referenties toe te voegen:
DUET: A Framework for Building Secure and Trusted Digital Twins of Smart Cities
IEEE Internet Computing
Lieven Raes; Philippe Michiels; Thomas Adolphi; Chris Tampere; Thanasis Dalianis; Susie Mcaleer; Pavel Kogut
2021

City of Things: An Open Smart City Vision and Architecture
Stefan Lefever, Philippe Michiels & Rob Van den Berg,
2019
https://www.imeccityofthings.be/drupal/sites/default/files/inline-files/open_city_vision_paper_final_0.pdf

Building Urban Digital Twins
Stefan Lefever (imec), Philippe Michiels (imec), Raf Buyle (Flanders Information Agency)
2020
https://inspire.ec.europa.eu/sites/default/files/inspire2020_dt_philippemichiels_rafbuyle.pdf


Overweeg toe te voegen onder brokers: rol van SDM
Data brokers make datasets findable and accessible but it takes more to unlock the full potential of data. Smart data management can be used to make the data interoperable and most of all reusable. Smart data management is the key to dealing with issues such as data lineage, data licensing, access control, data quality, etc.

--Tanguycoenen (overleg) 30 mrt 2021 14:11 (CEST) Good suggestion. Added the following, linking more to the initial definition of Smart data: Data brokers make datasets findable and accessible but it takes more to unlock the full potential of data. Smart data management can be used to make the data interoperable and most of all reusable. Smart data, according to Pieterson (2017) focusses on:

Utility: the potential utility derived from the data Semantics: the semantic understanding of the data] Data Quality: the quality of the data collected] Security: the ways data are managed securely Data Protection: how privacy and confidentiality are guarded These are all key aspects to take into account when building Urban Digital Twins.


Overweeg sectie toe te voegen na data broker: asset registry
Making data reusable, in turn is a foundation for reusable Digital Twin Components ranging from data processing pipeline components over simulation and ML models up to visualization tools. This will make the scope of brokerage expand to include mapping, component and model brokerage. The term asset registry has been coined to delineate this broader scope.

--Tanguycoenen (overleg) 30 mrt 2021 14:18 (CEST) Who coined this term and can we refer to a place where it is described? Also, why not be more specific and use the term "data source and model registry"?

Overweeg toe te voegen in de conclusie
Na de zin Finally, we have have explained a number of Open Urban Digital Twin cross-domain decision support use cases which are important to various consulted cities.

Benadruk de nood aan holistische benadering.

Where these cross domain use cases are important, they only scratch the surface of what digital twins are capable of. A more holistic approach towards capturing city data and combining these data streams towards AI applications may yet allow for more interesting use cases that allow to uncover less evident correlations between the different domains.

--Tanguycoenen (overleg) 30 mrt 2021 14:26 (CEST) Good suggestion, Thx. Inserted it as follows: "Where the presented cross-domain use cases are important, they are only examples that scratch the surface of what digital twins are capable of. A more encompassing approach towards capturing city data and combining these data streams with ML applications will allow for more and more interesting use cases to be supported. "


Andere opmerkingen en suggesties

  • Overweeg hernoemen Decision support phase naar Desicion support scope --Tanguycoenen (overleg) 30 mrt 2021 14:29 (CEST) Changed it
  • Overweeg herformulering van de zin they should use semantic technologies to allow different types of components to talk to each other and they should facilitate architectural integration of heterogenous components naar They should apply the latest techniques and insights around smart data governance, data semantics and data schema to ensure that their components can interoperate with little or no effort.
  • In sectie Data sources: extra capital IN addition to ...
  • Zelfde sectie: summier voorbeeld context. Overweeg toevoeging sensor kind, calibration settings, ... --Tanguycoenen (overleg) 30 mrt 2021 17:24 (CEST) Thx, changed to: "like e.g. the GPS location of where the sensor measurement was taken, the kind of sensor or the sensor calibration settings."
  • Sectie Models: porcess- en data-centric models: Referentie? Is dat hetzelfde als statisch versus dynamisch? DEF statisch is dat gegeven dezelfde input of twee verschillende tijdstippen geeft het model dezelfde output. Zo ja, vermeld. Zo nee, verduidelijk. --Tanguycoenen (overleg) 30 mrt 2021 17:31 (CEST) I do not have a reference for this, but a ref is not per se necessary, according to my understanding, if you explain the concepts well. If we think there is a more appropriate and well know defintition that covers the same ground, I'm happy to change the nomenclature. Is it the same as static vs dynamic: perhaps, but another way would be to say static vs learning.
  • In sectie process-centric models: typo ... the initiative to make changes to the model leis ..., should be lies - --Tanguycoenen (overleg) 30 mrt 2021 17:31 (CEST) Thx - changed

--Tanguycoenen (overleg) 31 mrt 2021 14:13 (CEST) Stefan, I took out the part you added in the models section. I wanted to rewrite it to make it more clear, but I am not sure what you mean to convey, so I think we should discuss this in more detail. The text read as follows: "Models can be used in different phases of resolution, from analysis models in case driven scenarios such as the environmental impact of an urban change to understand cause and effect, over simulations models adding time to the analysis to have more insights into general behaviour, to digital twin models adding possible real-time or sensor output to be able to resolve the "actual" operating state and performance. "

--Tanguycoenen (overleg) 31 mrt 2021 14:22 (CEST) Stefan, you added this: https://vloca-kennishub.vlaanderen.be/vloca-kennishub/Open_urban_digital_twins#Model_management_.26_governance I have some questions about it:

  • "These functionalities require model management, service and process management techniques. " => what are service and process management techiques?
  • The title of the header is "Model management & governance" yet you do not seem to talk about model governance?

--GertDegreef (overleg) 15 apr 2021 10:28 (CEST)

  • Suggestion about the 'brokers' and subsequent chapters about Smart data management and context management: I would mention the context broker and context graph together, not in seperate chapters. In my understanding (but correct me if I'm wrong), and in the specific case of the UDT, the context broker will use the information contained in the context graph and link the data to specific - mostly physical - attributes of the city. 'context graph' on itself is a broader term, just like 'context broker' (e.g. in the case of medical records the context broker links information to an individual (patient), and it also uses a context graph (mainly a 'master patient index')). If we mention both terms together, we can focus on UDT specifics, and avoid confusion with the broader definitions.
    • --Tanguycoenen (overleg) 27 apr 2021 11:09 (CEST) But if I am not mistaken, the context graph is used for more than just the context broker, which is why we discussed it in the part on the data broker and not in the part of the context broker.
  • Regarding "User interface" chapter: We - very correctly - state that the power of an UDT comes from its data layer. The need of an UDT to be highly extensible with data sources that are linked through graphs also imposes that the UI should response to this knowledge : a dynamic UI driven by the metadata known in the system regarding models and data is a challenge that we need to address when building UDTs. It is worth mentioning a paragraph on this here.
    • --Tanguycoenen (overleg) 27 apr 2021 11:14 (CEST) Yes and this is a very good point. I'll see what I can come up with for the release of V1, but otherwise, it will need to be something we described and expand on in a future version. Also, and this is also a reason to discuss the knowledge gaph separately from the brokers, Philippe told me that the knowledge plays a key role in allowing the UI to react to key changes in the state of the UDT, so this is also part of the answer, I would say. Right? I added some text to clarify this, in the UI section: "In addition, the UI needs to be able to deal in a flexible way with the variety of current and future states that the city will reside in. This requires an event publication mechanism that used the semantic data in the context graph to allow the user interface to present the right type of information to the right type of end-user type."
  • Suggestion on the 'conclusion': call it 'paper' instead of 'white paper' so that it is clear that we want input and comments.
    • --Tanguycoenen (overleg) 27 apr 2021 11:14 (CEST) Are you sure that just calling it a paper invites input and comments? We certainly want to invite these, but I would rather do this by explicitly mentioning it in the intro, which I think would be more cleat.