Re: Putting Government Data online

Danny,

I never raised any objections to URIs.  In fact, the ISO standard
for Common Logic supports them as names.

 > ... for FOL this may be trivial, but in the context of the Web
 > it's hugely powerful, the possibility of using a simple protocol
 > to retrieve more information about the topic at hand.

I am always in favor of supporting simple but powerful things.
What I am against is making simple things difficult.

My recommendation for the next version of the Semantic Web
is very simple:

  1. Keep the URIs.

  2. Replace RDF with JSON (which is as readable as any of
     the recommended syntaxes for triples, but it also supports
     n-tuples).  (And JSON, by the way, is the notation that
     Google uses instead of RDF.)

  3. Replace OWL with a DL that has equivalent logical power,
     but a much cleaner syntax and the ability to use JSON.

  4. Adopt ISO 24707 for Common Logic as the semantic foundation
     for multiple dialects.  For example, a Horn-clause subset
     or a DL subset would be two different subsets of full CL.

  5. Use a tag such as <script> ... </script> for embedding such
     notations in a web page.  (But Common Logic also supports
     an XML-ified dialect called XCL, which is more compact than
     RDF for triples -- and it also supports full Common Logic.)

I realize that some people claim that triple stores are useful,
but there are far more efficient internal representations that
give the programmer (or the logician) a view as either tables
or as graphs.

For just one example, see the following paper:
 
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=911FFAC5BC8B7B7A60B5E9197850E6AD?doi=10.1.1.52.3727&rep=rep1&type=url&i=0
The GMAP: a versatile tool for physical data independence

Tsatalos, the first author, did the work for his PhD dissertation,
in which he demonstrated that Gmaps (Generalized Combinatorial Maps)
provide a physical representation that is more efficient for SQL than
conventional tables and more efficient for object-oriented access
than conventional graphs.  He was hired by IBM Research, but as might
be expected, he was not able to budge the DB2 behemoth.  So he left
IBM to start his own company.

For our company, VivoMind Intelligence, we use Gmaps to represent
graphs, and they support very efficient operations with very compact
code.  Gmaps are also widely used in architectural systems to represent
huge graphs with billions of nodes.  They enable graphs that represent
a building or a complex of buildings to be mapped to any perspective
for virtual reality -- and the mappings are extremely fast, even on
huge graphs.  They can run circles around anything that could be done
with SPARQL.  And as Tsatalos showed, they can support SQL-like
queries against arbitrarily large graphs.

That is just one example of Knuth's dictum:  "Premature optimization
is the root of all evil."  The choice of triples to support the
implementation of triple stores was a premature optimization by
people who did not understand the state of the art for processing
graphs.

John

Received on Friday, 26 June 2009 10:17:33 UTC