15:06:10 RRSAgent has joined #transportation 15:06:11 logging to https://www.w3.org/2021/03/10-transportation-irc 15:06:13 RRSAgent, make logs Public 15:06:14 please title this meeting ("meeting: ..."), ted 15:06:20 Meeting: City Data Model 15:06:56 Clemens shares screen, Ken's framework document 15:07:09 Present+ Ken, Mark, Megan, Clemens, Ted 15:07:41 Clemens: Megan added wikinotes to the table and I integrated my comments with hers 15:08:03 … in general we have terminology differences we need to align 15:08:15 … there is a table below that goes into details on the different elements 15:08:35 … what we have in wiki is page name, usage, supplimentary figures but not description 15:09:01 … license information added, drop down or free notes 15:09:24 … subdomain goal as part of the use case we don't have yet. we need to decide if we want predefined lists 15:09:57 … we have actors and other stakeholders 15:10:11 Megan: highlights from Ken's document, hadn't looked at the raw file 15:11:01 Clemens: I added comments in red, Megan green but those don't show, just the yellow in raw view 15:11:23 Ken: markdown differences is what I suspect 15:11:46 Clemens: tabular style a bit off 15:12:00 … we have what data needs to be provided by and to actors 15:12:14 … we just have freeform text for data flows 15:13:14 … I think we have basic flow of events in there 15:13:35 … the wiki doesn't support multiple scenarios for each use case 15:13:51 … there are some other free text fields Megan noted would be needed 15:17:35 … business rules and technology constraints use is unclear to me as is geographic scope - city, block, neighborhood, region...? 15:18:50 … in information viewpoint we have long list of topics we want to answer 15:18:59 … I started going through how we want to address 15:20:18 Megan: I think we have two separate topics, use cases and fields 15:21:02 … I had same sort of questions as you did. the discussed views are not captured presently in the wiki 15:21:22 … logical data model, data dictionary etc need definitions provided below 15:21:56 Clemens: we have this logical data model but with classes, attributes and properties we have something like a logical model, do we derive it or use a separate one? 15:22:20 Megan: in the table you're showing, we have concept of business terms and how they relate whereas the other models look at data elements 15:22:35 … is class more business terms and what is distinction 15:23:56 Ken: the ontology general models major classes and complex items. when you get into details that is more at the logical data model 15:24:03 … ontology is key business terms 15:25:02 Mark: you're right. although ontologies allow you to define down to whatever level of specificity you want, the instances of eg color can be defined elsewhere and extend the ontology as it sees fit 15:25:34 … we're not intending to provide that level of detail. we are more at the information viewpoint level, major classes and properties 15:25:49 … relationships with other classes... 15:26:36 Ken: that is what I'm calling the conceptual data model. all the data that might be of interest to systems would be specified but you don't necessarily present representational form 15:28:04 Mark: we can leave it as range for a property (vehicle speed example) or we could specify units 15:28:18 … we don't want to overcommit for what we're trying to do 15:28:29 Ken: we just need to identify how deep we want to go 15:28:57 … within a city data model. if people want a deeper specification with more detail, we just need to provide link 15:30:04 Clemens: I am still a bit concerned that we are going to get all the information requested 15:30:30 Mark: we had a conversation about a minimum set of points provided and not overburden what people should be provided 15:30:42 … if staying at conceptual level, a number of these issues become irrelevant 15:31:05 Megan: for this effort would we not go into logical data model? 15:31:14 Mark: that is where my mindset has been 15:31:37 Clemens: this says concerns within our scope and makes clear what we don't address 15:32:00 Mark: we will have enough challenge getting conceptual model 15:32:21 … taking things down to lower levels will reside at the different SDOs 15:32:57 Megan: do we define the connection to those levels or leave it to SDOs? 15:33:21 Mark: when people propose new concepts or patterns, to the extent they want to discuss how it connects to lower levels 15:33:40 … I am happy for them to describe that in the description portion but that is not where we are trying to achieve agreement 15:34:36 Clemens: would we provide guidance on what can be put in description fields? 15:34:41 Mark: I am fine with that 15:34:54 Clemens: 20+ fields may be a bit overwhelming to people 15:35:21 Ken: we can identify fields that need to be filled in and would like to see a way to manage what may become a very long list of use cases 15:36:27 Clemens: that is valuable to add so we can organize it 15:36:47 … can we organize wiki with subpages? 15:36:52 Megan: that would be possible 15:37:10 … we discussed coming up with an initial set of domains to provide initial organization 15:37:23 … avoid similar/redundant domains 15:37:31 Mark: agree having a top level would be good 15:37:43 Clemens: and examples for subdomains 15:38:27 Ken: ITS may have a good list for smart transportation 15:38:52 Clemens: we need to try to get use cases into domain buckets and see if that prompts reorganization 15:39:06 Megan: should we look at the fields that are up in the air and define today? 15:39:12 Clemens: for use cases? 15:39:15 Megan: yes 15:39:44 Clemens: summary is a short abstract we would need to add. it is a hassle to have a short and long description 15:40:13 … illustration is perhaps figure 15:40:29 Megan: I kept that generic but we may want to distinguish what they are 15:41:06 Clemens: information flow diagrams, etc can be provided 15:41:28 … we don't want to update wiki model and fine with generic upload figure and we can distinguish what it is visually 15:41:46 Ken: do we allow multiple figures to be uploaded? 15:42:07 … and then we would need to number or organize them 15:42:09 Megan: it currently allows that, you just need to name them 15:42:27 Clemens: we need a way to reference them 15:42:35 Megan: I'll make sure labels are displayed 15:42:53 Clemens: we have business rule assumptions. that would fit into description potentially 15:43:21 Ken: think I created this template from what some other group had developed, traced it to our concerns and items in yellow didn't match 15:43:31 Clemens: staying on conceptual level reduces that 15:43:49 … key words, geographic scope, temporal, if we can drop those likely not a big issue 15:43:53 Mark: I agree 15:44:17 Ken: I'm fine with that. I was pulling in information from different sources and wanted us to be able to argue for or against 15:45:19 Megan: if we have a short summary it should contain the goal 15:45:26 Clemens/Ken: that's fine 15:45:59 Clemens: we have participants and other stakeholders, I see those as actors 15:46:14 Ken: stakeholders may not interact with system and thereby not be actors 15:46:23 Clemens: do we want to distinguish 15:46:28 s/ish/ish?/ 15:47:41 Ken: worth capturing who you want to pull into defining 15:48:33 Megan: does identifying those other stakeholders change understanding of use case? 15:49:04 Ken: one of the key elements of developing use case is getting a hold of those stakeholders to develop that information 15:50:09 … we can be clear what we don't address in our documentation 15:50:46 Clemens: then we had extensions/inclusions 15:51:06 Ken: optional flows, events and how you link use cases together 15:51:19 … we could define separate use cases for each variant 15:51:33 Clemens: I would include small variations in description 15:51:40 … use case diagram we covered with figures 15:51:59 … scenarios is one of the questions, currently we only have one but assumption was there could be multiple 15:55:20 Ken: we might want to break out exceptions field 15:59:15 Clemens and Megan discuss auto-population of data flow 16:00:27 Megan: we are building use case and defining the data flow, creating definition for those key concepts 16:01:00 Mark: I would use defined classes instead of required or maybe linked or defined classes/properties 16:01:39 Ken: object classes might not exist yet but may want to list out data needed 16:01:49 Mark: then we have to distinguish 16:02:53 Clemens: part of process of creating a good use case is providing its information requirements, eventually defined and linked but could be initially just text 16:03:03 Mark: we can have required and defined 16:03:17 Megan: defined should be auto-populated 16:03:33 Ken: requirements as free text 16:03:39 Mark: agree to that too 16:04:39 Present+ Ingo 16:05:48 Next meeting 1 April 10am ET 16:05:50 I have made the request to generate https://www.w3.org/2021/03/10-transportation-minutes.html ted 18:30:52 Zakim has left #transportation