Amanda and Leo, (01)
AV
> A further point: some folks (AFAICT, people who have done little work
> with FOL or HOL based systems) will argue, or simply assert, that more
> expressive languages make the representation work harder (because they
> are so complex or have harder to understand elements, like quantifiers). (02)
Unfortunately, there is a tiny kernel of truth to that, but it's not
because of the complexity of the logic. It's mostly a result of having
no guidance about where to start. (03)
The more restricted languages are designed to collect a narrow range
of information, so they give users some guidance for that tiny subset. (04)
That is one reason why I recommend a combination of diagrams with CNLs.
For example, each UML diagram is designed to capture one kind of info
in one highly restricted way. For OWL-like stuff, the class diagrams,
Entity-Relationship diagrams, and component diagrams give you 99% of
what is contained in the published OWL ontologies. For the more
general stuff, you can use controlled English to say anything else
that needs to be said. (05)
As for simplicity, I was just looking at a recent W3C note that was
trying to explain the semantics of blank nodes in RDF. The point
is absolutely trivial: (06)
1. A blank node represents something that is known to exist, but
whose identity is unknown. (07)
2. A name can be associated with that thing for further references. (08)
3. The type of thing can be specified with a monadic predicate. (09)
There is nothing more to say. But if you type "blank nodes in RDF"
to Google, you get 16,100 documents that use the most convoluted
gobbledy-gook to explain something anyone can say in English with
the phrase "There exists something of type T, which we'll call x."
And then you can mention x when you want to add more info. (010)
It's trivial, but these people publish papers in refereed journals
about how they "webified" logic. It's pathetic. (011)
Leo
> Currently we are developing an access policy model (OWL ontology
> and instances), translating these to Prolog, then translating
> the Prolog to efficient representation, i.e., by extensionalizing
> as much as possible (driving rules to ground, tabling, etc.),
> bit-encoding, etc. (012)
For our VivoMind work, we use three languages: Prolog for all
the advanced AI stuff; C for those algorithms that have been
thoroughly debugged, frozen, and optimized; and Java for the
user interfaces. We also use controlled English for definitions
that are translated to Prolog and/or conceptual graphs. (013)
We routinely translate SemWeb stuff to Prolog and get a huge
performance increase over the native SemWeb software. But that
is partly because we have a lot of Prolog predicates that are
just calls to C subroutines. (We tried using C++, but it just
causes bloat without much, if any reduction in programming time.) (014)
John (015)
_________________________________________________________________
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/ (016)
|