In an earlier note, I wrote: (01)
> My recommendation is to support everything, and let developers make
> their implementation choices on a case by case basis. Those choices
> should be decoupled from the logic and ontology. (02)
But that is easier said than done. To be specific, I started to
specify a family of languages and a methodology for using them
that can support *every* tool that uses any declarative notation,
graphic or linear, to represent semantics. The basic ideas are (03)
1. Use Common Logic to define the semantics, but do *not* require
anybody to implement the full CL semantics. In fact, nobody
should need to implement anything more than whatever subset
of logic they are already using or intend to use. (04)
2. The Natural Semantic Language (NSL) is a subset of the more
general Common Logic Controlled English (CLCE). But CLCE is
too big to be completely implemented all at once. Furthermore,
there are few tools available that could use the full expressive
power of CLCE. No subset of NSL 1.0 goes beyond the usual first
order logic, and most subsets use much smaller subsets of FOL. (05)
3. Various tools and methodologies use subsets of logic designed
for particular kinds of applications. To support them, NSL
includes *subsets* that map to the notations for those tools.
Any application that uses one or more of those tools can use
one or more subsets of NSL to specify the application. (06)
4. Since NSL 1.0 is limited in expressive power to classical FOL,
any project that uses two or more subsets of NSL can combine
them in one FOL specification. Therefore, any tools designed
to test or verify FOL specifications can be used to test the
combined specification. (07)
5. Unfortunately, many notations and tools include specialized
features (quirks) that are incompatible with the quirks of
other notations and tools. And some notations don't have
any formal definition, while others may use logics beyond
classical FOL. Therefore, a subset NSLX that is intended
to be mapped to language X might only express a subset of X:
some statements written in X can't be mapped NSLX. But they
might be mapped to NSLFOL or to a procedural notation called
NSLCommands. (08)
6. Since few, if any, applications are implemented in purely
declarative logicbased tools, there must be some way to relate
the logic to the procedural code. To relate them, the language
called NSLCommands includes imperative clauses that can call
external procedures. For each imperative clause, preconditions
and postconditions can be expressed in NSLFOL. Any collection
of statements in NSLCommands can be expressed graphically as
a Petri net (or a UML activity diagram) annotated with constraints
expressed in NSLFOL. (09)
7. There are many desirable extensions beyond NSL 1.0. One of the
most important is NSLTime, which would include enough ontology
to specify times, places, situations, and relations among them.
Another is NSLCollections for sets and plurals. And systematic
methods are needed to handle the nonmonotonic aspects of SQL,
SPARQL, and Prolog. But they won't be included in NSL 1.0. (010)
Many details must be specified for all these subsets, and there
are possible conflicts and tradeoffs among different subsets.
The full specification of the NSL subsets should be a collaborative
effort with people who have experience in using and implementing
each of the target languages. (011)
I plan to post more details about NSL and a grammar for the full
NSL 1.0 and various subsets on my web site. Summary below. (012)
John Sowa (013)
____________________________________________________________________ (014)
All NSL 1.0 subsets have a compatible semantics that is defined by
a mapping to firstorder logic (the plain vanilla predicate calculus
or its equivalent in any dialect of Common Logic). But each subset
also has a mapping to widely available tools: (015)
1. NSLDL uses the notation of Aristotle's syllogisms to map
to the widely used EL subset of OWL and/or to UML class
diagrams, ER diagrams, and component diagrams. (016)
2. NSLRules maps to Hornclause rules in many notations, including
Prolog, RIF, RuleML, and Datalog. NSLRules also has subsets for
each of the target languages. The Prolog subset is the largest,
and it includes the others as proper subsets. (017)
3. NSLData maps to JSON, which has a subset called NSLRDF. Any
statement in NSLData can be mapped to one or more statements
in NSLRDF by means of definitions written in NSL. (018)
4. NSLQuery maps to NSLSQL, which has a subset called NSLSPARQL. (019)
5. NSLDefinitions can define arbitrary Nadic relations in terms
of other NSL statements or in terms of mappings to external
languages. It can also define Nadic relations in terms of NSL
expressions with only monadic and dyadic relations. That would
support automatic translations from NSLSQL to NSLSPARQL. (020)
6. NSLConstraints supports a version of FOL that can be mapped
to OCL (Object Constraint Language) or to the SQL WHEREclause
for stating DB constraints. (021)
7. NSLCommands consists of imperative sentences that can be mappped
to procedural languages, the nondeclarative aspects of Prolog,
Petri nets, or UML activity diagrams. The semantics of external
procedures would be specified by preconditions and postconditions
stated in NSLConstraints. (022)
The syntax of the basic NSL clause is specified by the following
EBNF grammar rule (ISO/IEC 14977): (023)
Clause = Subject Verbal Object {PrepPhrase} (024)
The category Verbal includes simple verbs, but it also permits
phrases such as "has as part" or "is a part of". The angle brackets
indicate zero or more prepositional phrases. Without prepositional
phrases, this syntax supports dyadic relations (triples). With N
prepositional phrases, it can represent relations with N+2 arguments. (025)
NSLDefinitions can be used to expand any clause to RDFstyle triples.
For example, the following definition specifies a 4adic relation
by an expansion to three triples: (026)
Define "x1 sells x2 to x3 for x4"
as "x1 sells x2, x3 buys x2, the price of x3 is x4". (027)
As this example illustrates, optional variables are used instead
of pronouns. Each variable begins with one of the three letters
x, y, or z; it may be followed by one or more digits. Definitions
can also link NSL to other languages: (028)
Define "x1 sells x2 to x3 for x4"
as SQL(SELECT SELLER ITEM BUYER PRICE FROM SALES). (029)
We should also consider abbreviations that allow large numbers of
simple statements to be expressed concisely. But every abbreviation
must be specified by a syntactic translation to a statement in NSL. (030)
JSON notation, for example, could be used as an abbreviation for
anything written in NSLData. Other abbreviations to consider: (031)
dog < animal < living thing < physical object < entity. (032)
street address = 'http://www.w3.org/2006/vcard/ns#streetaddress'. (033)
x is the mother of y < there is a function from y to x. (034)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontologforum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontologforum/
Unsubscribe: mailto:ontologforumleave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgibin/wiki.pl?WikiHomePage#nid1J (035)
