Megan: based on governance and
other discussions have made some modifications to class
structure
... I have not yet made changes to properties and
guidelines
[Megan shares screen of her notes]
[will ask for copy for minutes]
Megan: I will provide a
walkthrough for creating a class
... if we go to class listing page and then into feature,
foundational concept regarding location
... this describes class at conceptual data model
... opportunity for formal definition. class could but doesn't
have to be a subclass of something previously defined in which
case it will be available in the dropdown
... in formal definition using Manchester syntax but could use
UML
... we can then link to other pages in wiki as the terms are
defined
... there is room for natural language description and provide
use cases
... definition status still something we need to settle wrt
governance
... not available to all users but to admins
Mark: close equivalent to rejected?
Megan: that was awhile ago but
believe so
... other two pages I want to look at are specifications and
specification element listings
... idea being we will be collecting input on common concepts
in model, we will need to reference the specification and
specific concepts within it
... we have a category for specifications, this is what an
example would look like [Megan has been sharing screen while
giving tour of collaboratory]
... we including an initial set of licenses and may need to
expand further
... here is an example of concept for route from
ISO5087-3
... we may want to specify a section of the spec. depending on
type of specification there will be different types of
definitions ranging from natural language to concrete
models
Ken: why would we detail individual specification elements as I fear we will get out of sync as those specs evolve
Megan: we want to take other
specifications into consideration and be able to contrast eg
our concept of route to others'
... this overview diagram is my thinking of the structure. at
conceptual level a common representation and want to map to
referenced specifications
Mark: perhaps description would be sufficient as definition may undergo change as Ken mentioned
Ken: I don't think I would even
go that far. my concern is we may set ourselves up. people will
be tempted to copy and paste getting into copyright issues
plus
... we want new creation text
... name of element, some description of that element and how
it relates to what we have in our model if not one to one
Clemens: more comment than an actual description
Ted: think we would be within fair use law but also ideally we can hopefully engage the spec editors to maintain their entries and can indicate when we have them doing so
Ken: there will be variation and inconsistency nonetheless, when would they update, when it goes to ballot, accepted...
Megan: there should be some
distinction between element and corresponding class. versioning
will certainly be an issue
... we will be referencing a dated or numbered version
Mark: we need to be able to reference a version of a standard without copying what that specification contains
Clemens: do we want version or
date as separate field[s] or in the identifier itself?
... we need to be clear which version we are commenting on
Ted: no strong preference but including in same field ensures visibility in different listing views
Clements: I would keep it as a text field
Ken: I want to ensure all fall
within a single page view, apart from perhaps any
discussion
... I also want traceability and we may not have proper
linkage/references to everything in a wiki based approach
compared to a database
Megan: these were my main questions about attributes, want to keep use cases at conceptual model level and not necessarily linked to specification elements
Ken: I see use cases as being higher than conceptual, think the way you have use case shown as fine
Megan: does it make sense that we
have this one view and potentially linked to classes and
properties or should we have a specification level
view/approach?
... any opinion either way?
Mark: based on what Ken was saying, separated out as you currently do
Ken: looking at your diagram
closer now, I think there is only one type of relationship
between an element of our model and specification
elements
... but you are saying there is one specification element for
our classes?
Megan: no, we have pages representing classes but also object properties and specification elements may correspond to classes
Ken: Ok, I understand question now and think the way to have it is fine, no need to distinguish properties and classes from specifications
Megan: namespacing at conceptual level something we need to have?
Mark: I don't think so
Ken: you don't see a need to
distinguish?
... at city level you may concept across multiple domains
Mark: I was saying no on the
basis as at this point we have yet to divide things up. when we
publish to github could see namespaces being applied
... notion of that grouping or labeling is appropriate, was
hesitating at formal namespacing
Ken: we can align namespaces as
we get ready to publish, in some cases utilizing existing
ones
... otherwise use our concept of domains of interest
... that could be a separate field for each element
Mark: services we see as
read/write capable, others only read capable
... that is a determiner if it exists citywide or separate
service
Megan: do we want to add this at this stage?
Mark: think we have to
Megan: we will need to come up with initial set for domains of interest
Mark: two pulldowns, one for read
only and other read/write
... maybe it is worthwhile to have list of services and those
checkboxes
Ken: presumably we just pull that list
Mark: looking at multiple SDO you can get clear set of services. Toronto has a service thesaurus
Ken: as ontology people we should clarify what we mean by service
Megan: any other comments or questions now that I have taken up most of our meeting time?
Mark: do we think we can get through scoping doc in ten minutes or move to next meeting?
Clemens: I think we can get through it since I do not have many comments
Mark: thank you Megan
Clemens/Ken: yep/that was great
[Mark starts sharing screen]
Mark: I leveraged some existing ISO 5087 project boilerplate for opening paragraph. third paragraph is where we get into more specifics
[[A common city data model enables city software applications to share information, plan, coordinate, and execute city tasks, and support decision making within and across city services, by providing a precise, unambiguous representation of information and knowledge commonly shared across city services.
The city data model is stratified into three levels of abstraction. The Foundation Level spans very general concepts such as Time, Location, and Activity. The City Level spans concepts that are general to cities and span many services such as Households, Services, Residents. The Service Level spans concepts commonly associated with a particular service but still shared with other services, such as Vehicles and Transportation network.
The short term scope is to develop a service level conceptual model, beginning with transportation. The criterion for inclusion in this model is that the concepts are "owned" by the service in the sense that they are instantiated and update by the service. Never the less, other services many have read only access to them. Concepts not used by other services are not part of this conceptual model.
The long term scope is to develop a city level data model. The criterion for inclusion in this model is that the concepts be both read and updated by more than one service. In other words the concepts are shared across multiple services.]]
Mark: any comments?
Clemens: I am fine with everything you written down, question whether TOCC is the right name whereas what you describe is larger
Ken: I am starting to use the term City Data Architecture in my governance document. this is essentially an architecture
Mark: understand that but tend to use architecture differently
Ken: it is JTC1 definition, what are the stakeholder concerns we are addressing
Mark: what about Common City Data Model and Architecture
Ken: ok with me, agree on broader level term
Megan: I had comment on short
term scope, purpose of this statment is to give us guidance on
how we will beging populating the collaboratory
... what is everyone's thoughts on getting around need to get
around lower level concepts?
... how do we do that without having foundation level already
defined or will those be our initial target definitions?
... you are right, we need approach of 5087 and instead of
long/short term more iterative of three levels
Clemens: so we would populate the lower levels to be able to address short term service level entries
Mark: yes, and we would leverage all the existing foundational level for things like W3C OWL Time
Clemens: sounds good to me
Mark: I will rewrite and cover
iterative approach, remove short/long term
... next meeting in two weeks?
October 22nd at 10 Eastern
Topics: Governance, refinements to scoping and collaboratory