On 4/3/2012 10:52 AM, Todd J Schneider wrote:
> ... from an OOR perspective the issue I attempted to raise was
> more pragmatic in nature. That is, we assumed that every OOR
> representation language module would have a way to graphically
> represent an ontology. (01)
General principles: (02)
1. Whenever you have a large specification of any kind, it's
impossible to visualize or even think about all the details
simultaneously. (03)
2. All popular visualization tools are designed to extract
and highlight certain aspects while hiding other aspects
or pushing them into the periphery. (04)
3. No single method of visualization can ever be ideal for
all possible aspects of anything. That's why UML started
with 6 diagram types and later expanded them to 11 and
then 14 types. There is no limit to the number of types
that might be useful for various purposes. (05)
4. There is only one kind of language that everybody finds
useful for every possible aspect of every possible ontology,
system, or problem: natural languages. (06)
5. Processing completely unrestricted NLs is still a research
problem, but controlled NLs have been used for over two
millennia for expressing ontologies. In fact, Aristotle's
patterns for syllogisms are a superset of the EL dialect
of OWL, which is the most widely used subset. (07)
6. In a note of March 20, I suggested the Natural Semantic
Language (NSL) as a systematic way of representing various
logics in a readable way. (Copy below). (08)
Recommendation: Provide tools that allow multiple views of ontologies
for various purposes. Users can select different views by pushing
a button, and they can dynamically choose which aspects or details
to highlight or suppress. (09)
One of the options is to define a mapping to and from NSL for each
of the ontology languages that are supported. Note that Adam Pease
and his group adopted a similar policy for representing every SUMO
statement in controlled English. (010)
John
_________________________________________________________________ (011)
Design principles for the Natural Semantic Language (NSL): (012)
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. (013)
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. (014)
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. (015)
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. (016)
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. (017)
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. (018)
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. (019)
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. (020)
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. (021)
John Sowa (022)
____________________________________________________________________ (023)
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: (024)
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. (025)
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. (026)
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. (027)
4. NSL-Query maps to NSL-SQL, which has a subset called NSL-SPARQL. (028)
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. (029)
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. (030)
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. (031)
The syntax of the basic NSL clause is specified by the following
EBNF grammar rule (ISO/IEC 14977): (032)
Clause = Subject Verbal Object {PrepPhrase} (033)
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. (034)
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: (035)
Define "x1 sells x2 to x3 for x4"
as "x1 sells x2, x3 buys x2, the price of x3 is x4". (036)
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: (037)
Define "x1 sells x2 to x3 for x4"
as SQL(SELECT SELLER ITEM BUYER PRICE FROM SALES). (038)
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. (039)
JSON notation, for example, could be used as an abbreviation for
anything written in NSL-Data. Other abbreviations to consider: (040)
dog < animal < living thing < physical object < entity. (041)
street address = 'http://www.w3.org/2006/vcard/ns#street-address'. (042)
x is the mother of y < there is a function from y to x. (043)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/oor-forum/
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
Shared Files: http://ontolog.cim3.net/file/work/OOR/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (044)
|