Hi,
I just noticed the obvious that escaped me so far …
I can optimize my program (to some non-trivial extent), by “lower-level” fact generation.
While, for example, i can have parts of the program work with generalized structures, like RDF, to enable maximum flexibility – I can generate along the side specialize facts with RDF predicates as functors – for those parts of the program that require more access speed.
It adds, “administrative” code cost – to keep those structures synchronized – and i, guess, I pay in memory costs … i am curious to see what speedups can be achieved.
Dan
optimization results are pretty dramatic …
Working against something like RDF where, for example, type information, must be navigated to across links – v.s. having type information encoded in a functor – is a dramatic difference – more than halving the access time.
Dan
This is interesting, I’d like to know in more detail. Facts can be accessed in about constant time if they are accessed via a hashable argument term because of the built-in clause indexing. If the same facts are stored with a compound term as the key, that might not be indexable and lookup will be linear time. If you have another type of memory structure for your RDF data, the access speed will vary depending on what you use.
Anybody: Does this work for time savings? Do the facts get indexed if key is suitable?
cached_lookup_rdf(Key, Result) :-
rdf_fact(Key, Result), !
; lookup_rdf_store(Key, Result), assertz(rdf_fact(Key, Result).
Hi,
I hope I wasn’t misleading with my comment. My case is slightly different and i am using RDF as an analogy only – since i have developed a built in quad store based on the frame-based conceptbase axiom system.
Suppose that in RDF(S) you represent an individual “Dan” as a first triple and other triples that classify Dan in various ways.
Dan is-a Person
Dan is-a Employee
Dan is-a Painter
If you now want to access type information you would need several rdf access.
Instead, whenever I instantiate a tripe into the triple (i.e my quad) store, i also generate a prolog fact such as is_a(dan, employee), is_a(dan, painter), is_a(dan, person).
I do this via code like this (with P standing for is-a and other predicates; S and O standing for triple the Subject and the Object):
T =… [P, S, O],
assert(T).
I further materialize this, to take into account transitive isa links – which in my case exists but to a limited extent only.
the latter description is significantly faster than when backtracking over the RDF store to retrieve the same “type” information.
Dan