Re: [dotNetRDF-Develop] Different means to accessing RDF

[Tomasz P. <tom...@gm...>]

Rob,

I think I can devise my own common denominator just for the sake of
executing SPARQL and that won't be a big thing. I would like to
confront you with some basic idea how I think the ORM solution could
work:

1. The mapping API is used to map .net types to some rdf classes and
their methods/properties to rdf properties. This could get complicated
if one wants to achieve a more sophisticated workflow. For example
saving triples for particular relation to another graph. A trivial
example could be that an example graph:

ex:FordFiesta a ex:Car ; ex:speed 150 ; ex:passengers 5 .
ex:HondaCivic a ex:Car ; ex:speed 160 ; ex:passengers 5 .

could be used to retrieve Car (this being a .net type) instances, each
having a integer-valued Car#Speed property.

2. The configuration API takes those mappings and creates a context
factory, which is used to wrap graphs, stores and endpoints thus
creating a context. A context will be something like NHibernate's
ISession or Entity Framewor's ObjectContext. The context is used to
access the underlying datasource transparently for example:

IEnumerable<Car> cars = context.GetAll<Car>().Where(car => car.Speed >
150); // transform LINQ into SPARQL
Car fordFiesta = context.Get<Car>("ex:FordFiesta"); // here possibly
do a DESCRIBE or a ?s ?p ?o query on the given source

I initially thought that for IGraph I could use simple triple-based
access but apparently the querying is quite complex from the start and
thus it would be a wasted effort, because at some point it would best
be switched to SPARQL anyway (hence my other SPARQL-building topic).

3. Accessing property values would have to differ based on the source.
For in-memory sources it is easy: if the requested triple is present,
retrieve a value. For remote sources perform a query to get the actual
value for the accessed property.

The question here is how do I best work with remote sources,
especially sparql endpoints. Does dotNetRDF provide some cache for
retrieved data, so that it isn't necessary to poll it every time for
the same triples. This seems easy to achieve for CONSTRUCT queries,
but how should it work for SELECT?

Looking just now at the interfaces IStorageProvider is likely what I
may suit my needs. Please confirm that I could/should use the
InMemoryManager to access in-memory graphs and triple stores and the
other implementations to access sparql endopints and third party
stores.

Thanks,
Tom

On Fri, Sep 21, 2012 at 10:30 PM, Rob Vesse <rv...@do...> wrote:
> Well IGraph and ITripleStore can both be wrapped by ISparqlDataset
> instances
>
> For remote things I am planning to write a dataset implementation that
> would wrap another query engine (I.e. convert the calls into SPARQL
> queries onto whatever the underlying engine is) because that helps address
> another open task I have but I haven't got very far with it just yet.
>
> So I'd recommend using ISparqlDataset as the common denominator provided
> you're OK with talking to remote endpoints via this interface not being
> supported just yet.
>
> Rob
>
> On 9/21/12 1:08 PM, "Tomasz Pluskiewicz" <tom...@gm...>
> wrote:
>
>>Hi Rob
>>
>>As you already know I have started working on a ORM-like mapper based
>>on dotNetRDF. I intend it to be as thin as possible and rely mostly on
>>the underlying powers of your library. To make it possible I have
>>defined an interfaces called IRomanticContext+dynamic proxies, which
>>will hide the details of how RDF triples and graphs are manipulated.
>>
>>The question I have comes form the fact the I need multiple context
>>types for different types of underlying data. I have indentified the
>>IGraph, ITripleStore, ISparqlDataset and BaseEndopint types, which
>>give access to various sources of RDF. Will I really need to wrap all
>>of those to provide a uniform abstraction layer over dotNetRDF? Is
>>there some kind of common denominator?
>>
>>Regards,
>>Tom
>>
>>--------------------------------------------------------------------------
>>----
>>Got visibility?
>>Most devs has no idea what their production app looks like.
>>Find out how fast your code is with AppDynamics Lite.
>>http://ad.doubleclick.net/clk;262219671;13503038;y?
>>http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>_______________________________________________
>>dotNetRDF-develop mailing list
>>dot...@li...
>>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop
>
>
>
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop