Re: Poll: RDF Use Cases

This is roughly what I am doing.  My implementation uses a single model
structure that morphs between a lightweight and heavyweight form depending
on the contents and usage.  Queries return either fully independent models
containing statement objects, or "views" that represent subsets of the model
being queried, and are "live" against that original model.

Models can also be easily enumerated, as in:

model.elements(), which returns an enumeration of statements

or

model.elements(STATEMENT_PROPERTIES), which returns an enumeration of the
property part of the statements

Queries can be chained:

model.query(q1).query(q2).elements(STATEMENT_OBJECTS)

I am fairly pleased with the syntax so far.

With regards to the time issue: We use a concept of "statement lifetime" --
a statement is valid from a certain time to an end time (which can be open).
I plan to use this and model set-combining to construct an efficient
MVTO-based transaction environment for RDF.

RJ

----- Original Message -----
From: "David Allsopp" <dallsopp@signal.dera.gov.uk>
To: "McBride, Brian" <bwm@hplb.hpl.hp.com>
Cc: <www-rdf-interest@w3.org>
Sent: Tuesday, December 19, 2000 10:52 AM
Subject: Re: Poll: RDF Use Cases


> I think this requires a query language that can specify sections of an
> RDF model to be returned as RDF documents, rather than queries which
> just return (arrays of) value(s). I might want to know about a
> particular resource, and may not want to send dozens of query messages
> (perhaps via a very slow transport mechanism) to extract each attribute
> of the resource - ideally I want to send one message and get back a
> serialized RDF model that can be stored or merged, and queried locally.
> Most current work on querying RDF seems to be oriented towards clients
> querying database servers (or webpages) rather than a peer-to-peer
> architecture with multiple RDF databases.
>

Received on Tuesday, 19 December 2000 12:32:45 UTC