Transportation Ontology Coordination Committee

<scribe> Scribe: Ted

<scribe> scribenick: ted

Mark: I came up with citydatastandard.org domain name

[acceptance on name]

Mark: Megan was going to work on manifestation of ontology, Ken you were going to work on UML administration and Clemens update to route use case

https://lists.w3.org/Archives/Public/public-transportation-data/2020May/0001.html

Megan: I sent this diagram (sharing screen) by email, representing change in our ontology design in more detail
... clarify questions raised last time
... around PD and ARC class
... real reason was to capture historical information we are capturing, timeline of data
... distinguish temporal and atemporal constraints in the domain
... ARC in a transportation network can only have one speed at one point in time without the temporal aspects
... you have one instance of ArcPD with multiple manfestations with invariant properties

Ken: I understand your model not and have many comments
... I would say a transformer is a time varying entity, truck, robot...
... if your list of attributes change for an entity I see a need. my node point can change due to road construction, it still connects two nodes but different now
... there are so few that can always be static, I question that model

Megan: from our perspective we want to come up with the identify criteria we are talking about. at the data level we still need to recognize the same Arc and be able to tie to that entity
... another reason is based on using OWL representation. it restricts us to binary relations

Ken: that can be handled with a unique identifier for the link

Clemens: we are not discussing yet how the consolidated route model would look like yet
... I am not sure we will end up something like this. what we are doing is describing the starting points we want to find common ground for

Megan: right
... we want to possibly pursue this as a model for routes or way to come up with a way to align our respective models

Mark: as Clemens explained this is to highlight how we are representing things in SmartCities model
... there are items and properties that are immutable over time, others do
... how to you handle them without overwriting the past. the question: what role does change over time play in this?
... how do we deal with vehicles' maintenance altering components or do we even need to?

Ken: I had opportunity to go through City Data Model site and develop questions, one is what exactly do we plan to represent?

Clemens: my understanding is we have these general concepts like route and Tpso and other representations
... we are working on these specific examples in order to try to find the common ground and try to build consensus on terminology and definitions

Mark: I am in agreement. the collaboratory needs to document the different approaches, see the breadth of things looked at, governance you are going to go through
... we will do this for other main classes/concepts we identify interest in aligning

Ken: my next question was how extensive a list we might come up with as that will influence how we will want to structure things
... alphabetical class listing can be problematic if this gets large

Mark: that is a good point, we are going to have to come up with categories of concepts
... our JTC1 approach has groupings already and what we are trying to do is not a deep dive
... we want to identify subset of concepts from city perspective useful in transportation
... is the concept of vehicle used and consumed

Ken: if it is not a citywide data concept it would not be in the citydata model at all or elsewhere?

Mark: TC204 has already done a deep dive, WG11 has voted upon and approved. there are other groups at the table
... from WG11 perspective we have foundational metrics and activity, citywide that are concepts produced and consumed by multiple services not just read by a single service, and lastly service specific such as maintenance records of bus
... that distinction I carry over to this coordination effort
... citywide and transportation intersect of interests from OGC, WG11, TC204 and W3C being our scope

Ken: understand the domain areas and they're important. when we show data in a domain area, is it consensus data in a domain area or is it a SDO's view?

Mark: I defer to answer Clemens made. we are trying to get the different perspectives at present and then try to identify the common classes
... as we get deeper into a domain the dependencies are more narrowly focused
... we do probably need a term of reference for what gets included in collaboratory

Ken: I think part of the key there is understanding the desired scope
... I am supportive of this
... it includes a complete representation of everything we know modulo IPR limitations on what we can cite

Mark: there will be a multiple of concepts from various SDOs and other organizations. we are not looking to represent that collective understanding but critical core of what should be common between them

Ken: as we pull in data from those various sources, based on the nature on how they're developed they will often have their own internal data models very different from ours
... having one coherent master data model for subclasses is what we can work on
... I will look at governance model I've been working on with this understanding in mind
... TC204 experts will be very interested and quickly contributing which means we need a clear structure that allows for a subdomain area to load up their data in our model
... we don't want us to become the bottleneck but decentralize and way for how it eventually gets elevated and accepted

Mark: I want to get something on screen for your input and then get update from Clemens on route. after we can use remainder of today's time on governance

Clemens projects citydata.utoronto.ca/index/Route

Clemens: I used an OGC link for namespace for now
... I tried to describe the main things I think are important based on comparison Megan and I did on Tpso and OGC approach
... I created in PlantUML a diagram, perhaps should have split into two since it is rather wide
... I did a few slight changes to make it easier to read and understand
... I started adding use case slightly abstracted from this on/offline discussion in scenario of the pilot
... this is not about travel planning but someone who wants to go from point A to B
... I have not yet added any data flows but it should be self explanatory
... not yet clear to me how to fill in all the data properties
... this does not yet have something for route segment, maybe lines up with Arc
... should I try to break it down into smaller pieces or this even the right direction?
... I noticed when I entered details and pressed submit there is a reminder that whatever is submitted gets the creative commons license
... in my case that is fine but when we want to collect from different sources and our governance we will need to figure out multiple licenses and IPR

Mark: that is an important point
... anyone posting anything as you did should also include license it is being made available under

Clemens: I thought about linking to OGC license

Mark: then we have to figure out what we want to use for exposing what we produce
... we should allocate more time for that on a subsequent call

Ken: I have detailed comments but we have limited time, how should I send those?
... email?

Clemens: better would be github issues as it produces a more public trail

Mark: collaboratory allows for comments as well

Ken: not on use cases, just classes

Megan: I can correct that

Ken: comments are linear instead of comment/response/resolution

Mark: is it possible to insert in here a reference to github issues?

Megan: I will look into it

Mark: I do not want multiple comment channels

Megan: we haven't identified the relationship yet between this content and the tocc github repo
... purpose of the citydata website was to pull in these different contributions and support idenfitying connections and github would be the actual encoding and development once extracted from that process
... is that what others have been thinking?

Ken: part of it is what are the capabilities to link them?
... it would be nice to have the PlantUML ascii text in github so we have history of changes
... what are the capabilities of the tools we want to use and come up with our process/flow based on that

Clemens: to include by URL would be helpful

Ted describes w3c.github.io and gh-pages branch

and perhaps use Travis CI for generating png

Mark: lets focus next meeting on governance and tooling
... Megan if you can examine that integration and limits that would help
... next meeting June 11 at 10am EST?