DARPA-ASKE / info-and-links

8 stars 3 forks source link

Meaning of "Syntactic constraints" #1

Open GEGlobalResearch opened 5 years ago

GEGlobalResearch commented 5 years ago

This entry moves an email conversation over to this repo. @crapo question:

I'm trying to digest the new slide 4 sketch and place our work into this context. I would really

appreciate some help with the meaning of "Syntactic constraints".

I think "Semantic constraints" is illustrated by our use case that "Mach Number = speed of flow/speed of sound", where semantic constraints tell me that "speed of flow" is the speed of the air flowing past an object in flight and "speed of sound" is the speed of sound it that air which is flow past the object. But what does "Syntactic constraints" mean and what would be some grounding examples?

@Jpfairbanks response:

I think the syntactic constraints are related to the ways of combining the primitives in the structural modeling level. So if you have structural models that are polynomial formulas, then the syntactic constraints are the rules for combining polynomials (with sum and product formulas). If you had models that are Bayes Nets, then the syntactic constraints are the rules for combining bayes nets (composition: c|b and b|a combine to form c|a and independence: p(a,b)=p(a)xp(b)).

I think the idea is that the syntactic constraints are the rules governing models that are application independent. So if I am modeling with a framework like ODEs the concept of stiffness is application independent but the concept of “air is a compressible fluid” is dependent on understanding the specific application context.

I’m not sure if that is what Joshua had in mind, but that’s my understanding.

@ewdavis response:

I'm chiming in to agree with James. His description matches my understanding. By the time models filter to the middle layer, semantic content like "flow is based on Mach number" should be replaced with the appropriate ratios, and measure conversions to ensure the ratios of rates, flows, etc, take these semantic facts into account and result in a model which is numerically correct. This relates to what was brought up during the meeting: "Semantic domain knowledge results in syntactic consequences".

That "air is a compressible fluid" below certain speeds likely has syntactic consequences; these need to be identified and embedded in the model before it is passed to the middle layer.

@pmjoshua reponse:

Yes, this sounds right to me. We didn't have a chance to flesh out this part of the architecture well but the idea was that concepts in a domain ontology have some meaning and are constrained as to how they can be combined with other concepts to form a conceptually valid model formulation (semantic constraints). These semantic constraints have implications for the structure of the representations in the middle layer and for meta-modeling procedures at that layer (such as transformation or merging type operations).

Would be great if people could flesh this out further with some examples in the materials they are producing this week.

@Jpfairbanks response:

Thanks Eric,

I think that things like an expression being well formed with unary and binary functions having the right number of arguments and balanced parentheses, type checking of computation to ensure that combinations of types are valid, unit checking, composition rules like f(g(x)) implies that g(x) is in the domain of f. Things like that are structural rules. They depend only on “structural” nature of the computation.

I think that unit checking spans all the layers. The fact that X(m)/Y(s) = (X/Y)(m/s) and you can only add quantities with matching units is structural. But the meaning of meters in terms of length and the meaning of seconds in terms of time is probably semantic/abstract. And you have to emit unit annotations for constants in the code you generate so that a compile time or run time system can verify your unitful computation.

Operationalizing the abstract/semantic layer knowledge is a lot harder. The practical distinction might be that the bottom layer has “knowledge that is operationalized as code” the middle layer has all of “the knowledge that can be operationalized algebraically” and the top layer has everything that is left. Although that certainly makes it harder to define. Does anyone have a good example of operationalizing the knowledge at the top layer?

jpfairbanks commented 5 years ago

Thanks for cross posting this @GEGlobalResearch! I am happy to move the follow up to this thread.