OPEN VCS, a lens for looking at models

I was asked if I’m proposing TGN as an API.

Here is my attempt at an answer.

FIRST, IT’S A PACKAGE OF DEFINITIONS

TGN, first, is a package of DEFINITIONS. Things defined in the package include definitions that already exist elsewhere but that are neither packaged, nor standardized uniformly (some applications honor the standard, some don’t).

For example, there are standards defining a camera and a camera path. But some apps honor one standard, other apps another, some do their own thing uniquely.

So, TGN is about gathering certain standards and normalizing them within the context of a certain set of functions packaged together.

If one or more developers decide to support the TGN concept, then we (or they) can determine which existing standard for camera paths (USD?) we want to call/incorporate into the TGN package.

Another definition among the 8 definitions in the TGN core (see the 8 features to be defined, in the page linked below this sentence) is the definition of extra (non-model) graphics.

Visual Engagement with Modeled Worlds

SVG is an existing standard definition suitable for this. SVG should be called by the TGN standard. Extra graphics that a user adds to a “TGN rig” within modeling app X will be authored using the code, methods, and format existing within app X. The TGN OPEN CODE that is added to app X will include:

— a standardized definition of extra graphics, in a standard format like SVG (probably SVG) and

— a code transformation layer that converts app X graphics to the standard graphics (SVG) for portability

Another definition among the 8 definItions of TGN OPEN CODE is for model filtering (model elements to show and hide). For filtering, as usual, there is diversity of methods across apps. But regardless of method, the product is always the same, a list of model element GUIDS. For portability, method calls are stored in TGN rigs but more importantly, the filter product, the list of GUIDS, are stored in the rigs so the correct show/hide filter can be expressed when the TGN is recalled either in the source app or some other app where the rig is shared and expressed. Obviously there are some dependencies involved in this, including access through a model gateway. This is discussed in “Admin Junk”, TGN feature 1.

HOW ARE THE TGN DEFINITIONS MANAGED AND IMPLEMENTED IN MODELING APPS?

After the DEFINITIONS, and the package of definitions, then there are the usual questions that follow from definitions:

(1) How are the definitions implemented in various existing modeling apps?

A codebase is developed, and implemented within various existing modeling apps. TGN OPEN CODE could be managed by a pioneering group of developers who decide they want to support TGN within their modeling apps. The developer team would develop the TGN OPEN CODE codebase, share it with each other, and promote it as an open standard within some standards body (like Apache, or something)

(2) How do users create and share TGN rigs with each other?

I see the answer like so many other typical examples. Like, how do users share PNG files with each other? Or how do users share drawings with each other? 

1. Some people are going to pass files back and forth to each other. If a building project has 2000 drawings, some people are going to create 2000 drawing files and send these files to each other.  Some of these will be grouped into sets, like on sheets.
2. But, many people say, “that’s chaos, so we use a web service to manage these files” or, OK, “things” if we don’t want to call them “files”

Like 1 and 2 for drawings, or for PNG files or anything else, TGN can operate either way, as discreet entities in some packaged form. TGN rigs are authored, shared, and expressed within existing modeling apps and shared by users across a project as TGNs are portable across multiple model-handling apps, expressed with adequate graphical fidelity in all modeling apps that support the TGN definitions. This sharing can be supported either by users exchanging TGN ‘files’ the old fashioned way, or within a managed environment, through web services. The latter, in the usual way, would keep TGN rig user edits up to date and available for any viewers to see the latest state of each TGN.

So, API?

The extent to which developers will implement TGN using API or other methods, I can’t say. It’s up to them. I advocate that a group of interested developers who want TGN in their modeling apps, decide to organize themselves into a TGN developer community (from one or more modeling app vendors), that they design the architecture as they see fit, and that they share the TGN OPEN CODE code base as a candidate open standard. 

And beyond the open core?

Beyond the 8 core features I described, that should be open (TGN), opportunity to extend the Attention Focusing Rigs (AFR) concept beyond the open core is a big space. Lots of opportunity. 

What about BCF format?

It’s nice but not enough. Some comments about BCF and TGN here:

Tom Cruise can stick to motorcycles and not return to sad jokes about poor engagement with, and misinterpretation of, digital models

Let’s get on the TGN boat

A number of companies state clear interest in TGN but getting them off the fence and into the boat is the next task. Bigger boat? I could mix more metaphors but better stop here.

There have been some things that go part of the way there including BCF (and my earlier work on drawing fusion) but they need to go further. That’s what TGN is about.