Dear John,
>
> I consider the current tools to be an early stage of what can and should
be
> developed. Note that UML started with 6 diagram types and later expanded
> to 11 types. I consider both 6 and 11 to be inadequate approximations to
> infinity, and I consider the current suite of SW logics to be inadequate
> representations of the full semantics. (01)
Yes, UML and SW logics are too narrow to adequate representations of the
full semantics.
There should be multiple languages to capture complex system of interest
with all needed modalities, reference libraries of regulation and industry
standards knowledge, real-time interactions during design, different slang
of specialty engineering etc. (02)
Discussion is constantly messing up different languages from minimum 3-level
stack (not to mention meta-languages for defining all of that):
1. architecture/requirements (systems engineering) language and multiple
specialty engineering languages (like P&ID or geometry, or simulations) that
should have concrete syntax and needs to be adopted by engineers.
2. representation languages for engineering languages data exchange
3. languages for programming of editors and solvers for engineering
languages (03)
In this language stack I can at least imagine engineers that use UML/SysML
with stereotypes in its visual syntax to do something (while I insist that
this is not too much). But OWL is definitely should be used only for data
exchange, not for use by engineers. (04)
Sure, semantic system should support all of these languages thus we have
more requirements to such a system. I should remark that semantic system
have not only structure facet (data representation, texts in multiple
languages etc.) but also processes facet, e.g. user interaction,
interactions with other systems (not reduced to merely "data exchanges"),
exectution of multiple solvers algorithms, etc. (05)
> Ideally, every aspect of system design should be specified in multiple
ways
> that can be automatically translated from one to another:
>
> 1. A rich, formally defined and highly expressive version of logic. (06)
Many people interested now in category theory as a new kind of mathematical
formalism.
Here one of the early works about category theory and ISO 15926 --
http://independent.academia.edu/OsmanBineev/Papers/1274311/Towards_arrow-the
oretic_semantics_of_ontologies_conceptories (07)
This is early work but is promising one. (08)
>
> 2. Subsets of logic that are specialized for efficient computation
> and implementation of various aspects of a system design and
> of the data it processes. (09)
Not all computation convenient express in logic languages. There are
contemporary general purpose languages that better suited for this purposes.
Insert them into this list. There is a lot of work on formal semantics for
these languages. (010)
>
> 3. Formally defined, but highly readable diagrams that are tailored
> to various aspects of the system. These diagrams could be mapped
> to and from the subset logics (point #2) and/or the full logic (#1). (011)
Logic can be used to represent data that will be processed with different
solvers (e.g. CAD/CAM/simulation software), not mandatory with reasoners
only. (012)
Diagrams are a visualized data. You can model data with a HOL and keep it
all not mandatory in RDF store. (013)
>
> 4. Controlled natural language(s) that can be mapped to and from any
> of the notations above (#1, #2, and #3). Some aspects are easier
> to see in diagrams and others are easier to explain in language.
> But we need both. (014)
We are working now with natural languages, not controlled natural languages.
COBOL was developed as a try to get controlled English but this was not
success. We have huge amount of legacy engineering knowledge about big
systems in natural languages. (015)
Nevertheless we need to use (and develop new) text languages for
engineering. Language Workbenches started with graphical languages but
quickly move to text-based ones. (016)
>
> 5. Mappings of all the above notations to and from the implementation
> languages for procedures and data. Those include procedural and
> declarative languages, and databases and data structures in any
> formats that are appropriate for any of the applications. (017)
This is important, but I am not understand about this "mapping". To me
"mapping" is one of the form of providing compilation/interpreting in data
domain. "Model transformation" is compilation/interpreting in
non-general-purpose programming languages domain. Therefore we need fusion
of mapping/transformation/compilation technologies. There are not too much
theory here yet but this ontologizing-modeling-programming unity is a key. (018)
When you work in *-in-the-large paradigm you enter also into another
problems. (019)
>From a software engineer’s viewpoint the mapping involves various external
system settings, program states, computer resources (memory, processing
power, network latency and bandwidth), interactions with user or multiple
users. If mapping for an online façade is not completed in a reasonable and
predictable time, it's useless. (020)
Using specialized restricted (e.g. logic only, or XSLT-type) languages it is
possible to specify quite effectively atomic rules (mappings-in-the-small);
but there are problems in the encoding of conditions and circumstances for
them (mapping-in-the-large). These are often left in plain text format as
gathered from specialists in legacy systems, without further formal and
executable specification. This in turn leads to process fragmentation and
manual execution of important tasks in the data conversion pipeline without
an ability to do a throughput testing for all potential choices and forks.
Practically the result of each data conversion has to be put through
validity test anew. (021)
In a modern programming language you can specify and test any type of
condition, internal or external, from a single process. Validity and
performance tests for time constraints, usability and business value can be
done for one mapping or for a complete data pipeline. (022)
It is important that you need not only "stack" of languages (like
microprograms, machine codes, Asm, Macro Asm, C, etc.) but
-- multiparadigm foundational language (not restricted as only logic-based).
It should be closer to Python or Scala then Prolog. All logic/reasoning will
be available in complex data structures of such a language and libraries of
different optimizations.
-- tools to define graphical and textual DSL in foundational language with
projectional (compile/decompile to foundational level) editing. Presence of
contemporary IDE (language workbench).
-- have a possibility of simultaneously usage of all these DSLs. (023)
We now using Python with some syntax tricks to do this. E.g. we have (ISO
15926 graph) Builder DSL. This is sample "mapping from table format to ISO
15926 graph": (024)
class_id = r.known('Class Name', ids)
superclass = r.known_or_empty('Superclass Name', ids)
rel_class = r.known_or_empty('Classifier Relationship Class', ids)
class_class = r.known_or_empty('Class of Classifier Classes', ids)
source = r.nonempty('Source')
if superclass:
rel_id = part2.Specialization(hasSubclass=class_id,
hasSuperclass=superclass, annSource=source)
if rel_class:
part2.Classification(hasClassified=rel_id,
hasClassifier=rel_class, annSource=source)
if class_class:
part2.Classification(hasClassified=class_id,
hasClassifier=class_class, annSource=source) (025)
We are developing similar (ISO 15926 graph) Scanner DSL. Mapping from ISO
15926 can be done with expressions like: (026)
entities = find(type=part2.Scale,
classifier=check(label=icontains('15926-4'))) (027)
This is very regular and can be abstracted further, general purpose
languages have multiple mechanisms for abstraction, "go meta" and other form
of reuse. But this is pure Python, and I can use (or not use) anything. (028)
>
> 6. Mappings of all of the above to and from annotations and comments
> nested in the data and program sources and/or in documentation
> that is keyed to the data and program sources. (029)
Yes, sure. Especially we need NLP processing here. But engineering NLP
processing is very special because we have "text with drawings, diagrams,
tables and formula" that will break any general-purpose language processor. (030)
This is also hardly "mapping" but rather "processing". (031)
>
> 7. A open-ended suite of tools that support all of the above. (032)
Yes, tools first and theory second.
I think that UML/SysML can survive due to abundance of tools on the market.
If we provide engineering IDE for another (ontology based) architecture and
product description engineering languages (DSLs, there are multiple kinds of
it). (033)
>
> I don't expect every component to be implemented all at once. But the
> formal logic in #1 must come first. Having a solid foundation enables
> developers to work independently on different pieces of the puzzle while
> ensuring that the semantics of each piece is a proper subset of the
semantics
> of the entire system. (034)
Big systems and great languages usually growth in another way: practicality
first, theory second. BPMN, UML, XML and all other "big successes" in
languages have this way. (035)
I guess that semantic system first will be developed and second it get
formal logic in it (Semantic System 2.0) ;-) (036)
>
> Note that I call this a framework for a semantic system. I consider the
> Semantic Web to be one important piece of the puzzle that focuses on
> points #5, #6, and #7 for data in WWW formats. But the formatting that
is
> efficient for one kind of application may be very inefficient for some
other
> application. Points #1, #2, #3, and #4 should be sufficiently general to
> accommodate an open ended variety of applications. (037)
Formatting is simply another word for "mapping" (transformation, compiling,
interpreting, processing). (038)
We at TechInvestLab not like WWW formats but able have output and input of
our programs in RDF/OWL. We can support Plan9 syntax if you need it. This is
due our accent to general purpose language as an important for semantic
system. "Semantic" and "ontology" is not privatized only to FOL or lower
reasoners and languages for FOL or lower reasoners. Any computation
(including those that coded with general purpose language) is based on a
logic -- modal, temporal etc. (039)
> For examples of how the design diagrams relate to the ontology
> specifications, I'd like to mention the following slides by Conrad Bock:
>
> http://conradbock.org/ontological-product-modeling-short-slides.pdf
>
> The diagrams in these slides can be specified formally. Incorporating
them in
> a framework such as the one above can go a long way toward making formal
> semantics acceptable for practicing engineers -- and that includes
mechanical
> engineers, chemical engineers, and even software engineers. (040)
Completely agree. I am always popularizing this work of Conrad Bock. I
consider that there are too few mereology in current systems engineering
(architecture description) languages, too few patterns to express
systems-of-interest life cycle in them, too few means to express
System/System components directly. We need to give to our engineers more
ontology-related features in architecture languages to they not have endless
discussions about their ontological commitments. (041)
I disagree with Conrad about: (042)
1. UML family as a basic language (it should be something else, it discussed
elsewhere). This is exactly a cause of this "[ontology-summit] INCOSE
Ontology Action Group, onto SysML/UML" discussion thread. (043)
2. Needs to use "folk" presuppositions in engineering languages. I think
that most powerful engineering languages will come with counterintuitive
presuppositions. This require separate discussion, this was not yet touched
in Ontology Summit 2012 (except my remark in one of the presentations that
ontology for big systems should be counterintuitive and a thread about
Systems component initiated by Matthew West). This is off-topic in this
UML/SysML tread. (044)
Best regards,
Anatoly (045)
>
> John
>
> ________________________________________________________________
> _
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2012
> Community Portal: http://ontolog.cim3.net/wiki/ (046)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community Portal: http://ontolog.cim3.net/wiki/ (047)
|