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 NSL-X 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 NSL-X. But they
 might be mapped to NSL-FOL or to a procedural notation called
 NSL-Commands.  (08)
 6. Since few, if any, applications are implemented in purely
 declarative logic-based tools, there must be some way to relate
 the logic to the procedural code. To relate them, the language
 called NSL-Commands includes imperative clauses that can call
 external procedures. For each imperative clause, preconditions
 and postconditions can be expressed in NSL-FOL. Any collection
 of statements in NSL-Commands can be expressed graphically as
 a Petri net (or a UML activity diagram) annotated with constraints
 expressed in NSL-FOL.  (09)
 7. There are many desirable extensions beyond NSL 1.0. One of the
 most important is NSL-Time, which would include enough ontology
 to specify times, places, situations, and relations among them.
 Another is NSL-Collections 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 trade-offs 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 first-order 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. NSL-DL uses the notation of Aristotle's syllogisms to map
 to the widely used EL subset of OWL and/or to UML class
 diagrams, E-R diagrams, and component diagrams.  (016)
 2. NSL-Rules maps to Horn-clause rules in many notations, including
 Prolog, RIF, RuleML, and Datalog. NSL-Rules 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. NSL-Data maps to JSON, which has a subset called NSL-RDF. Any
 statement in NSL-Data can be mapped to one or more statements
 in NSL-RDF by means of definitions written in NSL.  (018)
 4. NSL-Query maps to NSL-SQL, which has a subset called NSL-SPARQL.  (019)
 5. NSL-Definitions can define arbitrary N-adic relations in terms
 of other NSL statements or in terms of mappings to external
 languages. It can also define N-adic relations in terms of NSL
 expressions with only monadic and dyadic relations. That would
 support automatic translations from NSL-SQL to NSL-SPARQL.  (020)
 6. NSL-Constraints supports a version of FOL that can be mapped
 to OCL (Object Constraint Language) or to the SQL WHERE-clause
 for stating DB constraints.  (021)
 7. NSL-Commands consists of imperative sentences that can be mappped
 to procedural languages, the non-declarative aspects of Prolog,
 Petri nets, or UML activity diagrams. The semantics of external
 procedures would be specified by preconditions and postconditions
 stated in NSL-Constraints.  (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)
NSL-Definitions can be used to expand any clause to RDF-style triples.
For example, the following definition specifies a 4-adic 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 NSL-Data. Other abbreviations to consider:  (031)
 dog < animal < living thing < physical object < entity.  (032)
 street address = 'http://www.w3.org/2006/vcard/ns#street-address'.  (033)
 x is the mother of y < there is a function from y to x.  (034)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ 
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ 
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J  (035)