Kingsley, (01)
JFS>> What we do at VivoMind is to represent everything in conceptual
>> graphs and to index the graphs by a Cognitive Signature (TM) as
>> they arrive. When new graphs arrive, we compute their Cognitive
>> Signatures, check whether we ever saw anything similar, and
>> retrieve the previous cases. (02)
KI> Cool, the kind of thing you can also do over a cluster of servers,
> even if you provide SPARQL or SQL as entry points to the engine. (03)
That's true. The logical form (which is independent of the way
the data is organized) is fundamental. We use graphs as a very
general representation for the logical form. (04)
The SQL WHERE clause can be translated to a graph. The path-based
SPARQL is a more procedural representation of what some programmer
thought was the best access path. But that is just one programmer's
guess, and that guess might be good or bad. We would just ignore
the guess, reconstruct the query graph from the SPARQL path, compute
the Cognitive Signature, and find the best match in the index. (05)
KI> This is a very important point, as this is ultimately how the
> strange DBMS void between RDBMS (schema first; column or row stores)
> and Graph Model DBs (e.g. RDF Stores) will be bridged. (06)
In my first published paper on conceptual graphs I proposed CGs as
a notation for representing DB conceptual schemas that could also
be used as a bridge to natural language. That was in the IBM
Journal of R & D in July 1976: (07)
http://www.jfsowa.com/pubs/cg1976.pdf (08)
Ted Codd liked the general approach, and I collaborated with him
and his group around 1978 and 1979. They used a parser I had
developed in their RENDEZVOUS project for supporting English
queries to a relational DB. But at that time, I did not have
a suitable implementation of conceptual graphs for the semantics. (09)
Conceptual graphs are typed, since a concept such as [Employee: Lee]
has a type field (e.g., Employee) and a referent field (e.g., Lee).
Instead of a fixed, frozen schema set up by a DB administrator,
conceptual graphs assume a base set of 'canonical' graphs, which
can be combined by 'canonical formation rules', which serve as
a kind of graph grammar. (010)
The canonical graphs represent the type constraints defined by
an ontology, but new canonical graphs can be added as needed.
They enable the constraints of an ontology to be enforced, but
they also support dynamic extensions to the canonical graphs. (011)
And by the way, I'm not claiming a big innovation for proposing
a dynamic conceptual schema, because a lot of people at that
time had many proposals with varying degrees of extensibility.
My major complaint is that the people who developed the SemWeb
ignored the 50 years of R & D on that and many other subjects. (012)
John (013)
_________________________________________________________________
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (014)
|