Discussion item: disjoint theoretical model / encodings cityGML

[lvdbrink]

One of the key challenges around JSON encoding of CityGML v3 (like CityJSON might be) is the apparent disjoint in the development of the theoretical model and its physical encoding(s). Good practice suggests that validation of a theoretical data model through implementation and physical encoding can have a positive impact; making the model better. However, according to the current development plan of CityGML 3.0, the theoretical model will be going through the standards approval process before work starts on the creation of a physical encoding. As the SDW IG, do we have an opinion on whether implementation evidence is 100% essential in the standards process - even for conceptual models?

I raise the question here because this is relevant to CityJSON - one of the potential standardization candidates we're sheparding through it's incubation phase. Currently, CityJSON is being developed as an alternative encoding for CityGML 2.0. Basing it on version 3.0 has been considered, but @hugoledoux has concerns about the complexity of the proposed CityGML 3.0 data model from a developer's perspective. Wouldn't it be good to experience this by implementing an encoding, before the theoretical model is approved?

The CityGML SWG is an OGC entity, and will have their own discussion and resolution on this. However, as the SDWIG we could reach out to the CityGML SWG - if we think it's warranted and think having CityJSON is a good idea - to express our opinion. The SDWIG was created by OGC and W3C together to be a kind of intermediary between our communities - so it would fit our role.

For example, we could express to them that we see a need to define a web-friendly JSON encoding of the CityGML data model, that theoretical data models need implementations to challenge the design, and point out that we are in favour of an interactive process where data model and encoding of CityGML would be developed hand in hand instead of one after the other.

It would be good if we can get a conclusion (i.e. do we want to make such a statement as a group) ahead of the OGC TC in Stuttgart (mid-September). That way, we could communicate this to the SWG before they have their next face to face meeting.

[PeterParslow]

As far as I know, LandInfra / InfraGML was the first (& so far only) OGC standard to have taken the approach which CityGML 3.0 is now trying. And it's true that creating the GML encoding required approving a corrigendum (or minor amendment) to the conceptual model.

I will share ISO TC211's relevant experience here, as they have longer experience of agreeing conceptual / logical models and then generating encodings. TC211 now 'insists' that any project which creates / modifies UML models has a member of their 'Harmonised Model Management Group' (HMMG) involved - whose jobs it is to check that the model is 'good enough' to act as a source model in a model driven architecture for producing various encodings. And the TC won't (shouldn't) put the conceptual standard out for full vote until HMMG is happy with the model. The HMMG is now part of a 'Resource Management Group' involving also TC211's leads for XML encodings & ontologies (they haven't created a JSON encoding yet - first such project out for 'new project' vote at present). Here the idea is that in approving the model, HMMG has taken into account the capability of driving automatic XML and OWL encodings from it - so has tried at least a subset.

(opinions differ on the quality of the rule drive encodings, especially the OWL, but that's a different matter!)

That may well be a rigour which CityGML should be encouraged to adopt (& then OGC TC) - before the conceptual model standard is approved (or perhaps even before it goes for 'public vote'), the model must have been tested by creating an encoding.

[ogcscotts]

It is true that the LandInfra conceptual model was approved as a standard before the implementation parts were approved. Like with CityGML, very careful UML was developed in the conceptual model for Land Infra. I do know that the implementation work for Land Infra (standardized as InfaGML) was underway at the same time as those parts started the approval process pretty quickly behind the conceptual model. Minor correction to Peter's comment: there was not a corrigendum to the conceptual model, but it did get an update after the public comment period mostly as a result of the work on implementation.

We had an interesting debate at the 2015 Boulder meeting on whether UML or other modeling languages should be required in OGC standards. The results was "encouraged, not required." As other SWG talk about splitting their conceptual from implementation models, I think that a little more rigor in model evaluation will likely need to occur.

[lieberjosh]

It’s worthwhile to note that many conceptual models (and this goes for many OGC models and most of the more successful TC211 specs) have been developed as generalizations of specific implementation specs. That accords with the core vs simple principles discussed in the OAB, that general cores or concepts are often the result of experience with specific, simpler implementations. When considering a variety of implementations, it’s particularly problematic to start with a full conceptual model, not knowing what can be implemented in XML vs JSON vs OWL, etc.

As far as conceptual modeling technology, it’s always been a bit odd to call UML a language. It’s more of a graphical formalism, although I understand that work is being done at OMG on more interoperable XMI. The question is also raised nowadays whether OWL might be a more useful conceptual modeling language, for a number of reasons, including a more straightforward implementation path. One conclusion of the various debates on this subject has been, perhaps surprisingly, that a good model narrative is almost always useful whichever methodology is ultimately followed.

—Josh

On Aug 10, 2018, at 11:34 AM, ogcscotts notifications@github.com wrote:

It is true that the LandInfra conceptual model was approved as a standard before the implementation parts were approved. Like with CityGML, very careful UML was developed in the conceptual model for Land Infra. I do know that the implementation work for Land Infra (standardized as InfaGML) was underway at the same time as those parts started the approval process pretty quickly behind the conceptual model. Minor correction to Peter's comment: there was not a corrigendum to the conceptual model, but it did get an update after the public comment period mostly as a result of the work on implementation.

We had an interesting debate at the 2015 Boulder meeting on whether UML or other modeling languages should be required in OGC standards. The results was "encouraged, not required." As other SWG talk about splitting their conceptual from implementation models, I think that a little more rigor in model evaluation will likely need to occur.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw/issues/1069#issuecomment-412119968, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhupAhfISEC1kGbOXx5XxgbU96zctks5uPagNgaJpZM4V2HHQ.

[MichaelGordon]

Related to this is the current discussion going on the TC-Discuss mailing list regarding requirements for evidence of implementation before a standard can be approved: https://lists.opengeospatial.org/mailman/private/tc-discuss/2018-October/000813.html (requires OGC login)

[lvdbrink]

The SDWIG discussed this at our TPAC f2f and came to this resolution:

In principal, the Spatial Data on the Web IG strongly supports the need to create a feedback loop between practical experience implementing a spec and its design to create effective standards implemented by the wider community. The SDW IG will work on a formal response on CityGML v3 raising technical concerns to be sent to the tc-discuss OGC list."

See minutes.