RE: properties as nodes etc.

>In fact, i tried to do this in my first implementation of an
>RDF repository last year. But i quickly came back on my design
>since it was too expensive.

heh - you should see the price of Swing

>I now figured out that this kind of graph representation was
>cool enough for programmers to explore a graph. But that this
>should be materialized as an upper system above a simple
>ntuples repository and processor.

Interesting, not having tried to make a repository the problem hadn't
occurred to me. I suppose it makes sense in a model-view-controller kind of
fashion.

>My actual implementation is centered around a Model interface.
>The Engine interface enables to build models (Builder pattern).
>You may ask it for a ModelBuilder or a FormulaBuilder.
>
>My RDFXML, Triple and n3 parsers ask the main engine for a builder
>in order to load models into it. This separates implementations of
>syntaxes reading from implementations of engines.

That sounds very good - I'm afraid my different graphs are mostly created
using different concrete subclasses, though I did start an interface which
would take a (RDF) rule file to make it syntax-independent. I really should
build a builder though ;-)

>My MemoryEngine when populating one of its builders create either
>a MemoryModel or a RuleBasedModel (which i expect to derive soon
>from MemoryModel for base facts).
>
>All this is manageable via a MetadataService and MetadataInspector
>concrete classes.
>
>When you do a query to the MetadataInspector, it loads a formula
>corresponding to the query. It then runs the 'no-conclusions' rules.
>And returns a binding (a set of valuations eg.
>((a=...; b=...) (a=...; b=...)) ) where values are QNames and not
>concrete nodes!!!!

phew!

>I even yet don't know if i still want a graph API above this.
>Hoping it may help you.

It's very helpful, thanks. Even when folks make their source available it's
often hard to see the overall architecture, and harder still to guess where
they're going with it.

>The MemoryEngine is completely implemented
>in PHP. I will soon extract make an implementation of Model based
>on a relationnal db for it.
>
>BTW: I'm looking for some people to make an implementation of an
>Engine based on XSB. This is mainly a prolog (or flora which could
>be really simpler or whatever) generation task as we allready have
>a quite working PHP extension for XSB.

I for one wouldn't know where to start ;-)

Cheers,
Danny.

Received on Wednesday, 19 June 2002 07:22:00 UTC