Sounds fantastic! Something so simple coming out so, well, much later than xml? (01)
SGIS
Antoinette Arsic
Sr. Systems Engineer
8618 Westwood Center Drive, Suite 100
Vienna, VA 22182
703-506-8621
443-567-2703
aarsic@xxxxxxxx
www.SGIS.com
________________________________________
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
[sowa@xxxxxxxxxxx]
Sent: Wednesday, August 27, 2008 10:57 AM
To: [ontolog-forum]; standard-upper-ontology@xxxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Foundation Ontology (02)
As I said in previous notes, the Foundation Ontology should be designed
to use any or every logic-based notation as input, and the internals
should be stored in some suitable version of logic. (03)
For complex logical expressions, a full version of logic, such as the
Common Logic standard would be necessary. But a very large amount of
specification can be done in much simpler notations. RDF(S) and OWL
are widely used, but their human factors leave much to be desired. (04)
Recently, Google has released specifications and software for their
_Protocol Buffers_, which use a compact, elegant, humanly readable
notation that is also very efficient for computer processing.
Following is an example from their documentation: (05)
person {
name: "John Doe"
email: "jdoe@xxxxxxxxxxx"
} (06)
Following is an equivalent in XML (an RDF version would look worse): (07)
<person>
<name>John Doe</name>
<email>jdoe@xxxxxxxxxxx</email>
</person> (08)
For such a short example, the Google form is somewhat more readable
than the XML form, but the difference in readability escalates rapidly
for large examples. Just as important is the computer efficiency.
Compressing XML notations by ZIP or other algorithms takes an enormous
amount of time, but the Google software is extremely fast. Following
is their comment: (09)
> When this message is encoded to the protocol buffer binary format
> (the text format above is just a convenient human-readable
> representation for debugging and editing), it would probably be
> 28 bytes long and take around 100-200 nanoseconds to parse. The
> XML version is at least 69 bytes if you remove whitespace, and
> would take around 5,000-10,000 nanoseconds to parse. (010)
Following is the Google summary, which I find convincing: (011)
> Protocol buffers have many advantages over XML for serializing
> structured data. Protocol buffers:
>
> * are simpler
> * are 3 to 10 times smaller
> * are 20 to 100 times faster
> * are less ambiguous
> * generate data access classes that are easier to use
> programmatically (012)
The three primary languages they support are Java, C++, and Python.
But other groups have implemented versions for C, C#, Perl, PHP,
Ruby, LISP, Erlang, Haskell, and ActionScript. (013)
The above example came from the Google Developer's Guide: (014)
http://code.google.com/apis/protocolbuffers/docs/overview.html (015)
At the end of this note are some quotations from Google developers.
A very important point is that the Google notation with its supporting
software has been implemented and tested on very large applications --
probably some of the largest applications in the world. And the
software they are now making available (under the Apache license)
is already version 2.0, so the speed bumps have been smoothed out. (016)
Recommendation: I suggest that we use the Google notation to represent
simple type hierarchies at the level of Aristotle's syllogisms. That
is the most commonly used subset of OWL, and it can be automatically
translated to Common Logic, and every other notation that anyone has
been using for ontologies. For more complex expressions, a richer
version of logic could be used. But I would recommend a version of
controlled English as the *primary* notation for complex logic. Other
notations, including OWL or Common Logic, would be compiled *from*
controlled English. (017)
John Sowa
_______________________________________________________________________ (018)
http://www.informationweek.com/news/internet/google/showArticle.jhtml?articleID=208803049 (019)
"It's the way we encode almost any sort of structured information which
needs to be passed across the network or stored on disk," said Chris
DiBona, Google's open source programs manager, in a blog post. "We
thought Protocol Buffers might be useful to other people, too, so we've
decided to release it as open source software." (020)
Google software engineer Kenton Varda, in a post on the Google open
source blog, said that Google uses literally thousands of different data
formats, most of which are structured. Encoding these data formats on a
massive scale is too much for XML, so Google developed Protocol Buffers. (021)
Varda compares Protocol Buffers to an Interface Description Language
(IDL), without the complexity. "[O]ne of Protocol Buffers' major design
goals is simplicity," said Varda. "By sticking to a simple
lists-and-records model that solves the majority of problems and
resisting the desire to chase diminishing returns, we believe we have
created something that is powerful without being bloated. And, yes, it
is very fast -- at least an order of magnitude faster than XML." (022)
For Google's FAQ, see (023)
http://code.google.com/apis/protocolbuffers/docs/faq.html (024)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (025)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (026)
|