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

[Rob V. <rv...@do...>]

Ok, comments inline

On 9/24/12 5:25 AM, "Tomasz Pluskiewicz" <tom...@gm...>
wrote:

>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.

Yep, with you so far

>
>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.


For points 2 and 3 you might want to talk to Graham and Kal offline, what
you are trying to do sounds very like what they do with BrightstarDB

On point 3 take a look at Andrew Matthew's old LinqToRdf code, his
approach used class generation so not necessarily a direct parallel but
essentially he would have an intermediate reference to the value inside a
property and the first time it was accessed resolve it, this is
particularly useful for properties that establish relationships between
classes since it avoids having to build the entire object graph at one time

In essence lazy load

>
>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?

No there is no cache currently, for CONSTRUCT results just stick them in a
Graph/TripleCollection

Maybe the better option is to always use CONSTRUCT

>
>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.

Yes that would work, InMemoryManager wraps the in-memory query engine with
the standard IStorageProvider interface so using IStorageProvider as your
common denominator may work best for you

Rob

>
>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
>
>--------------------------------------------------------------------------
>----
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>dotNetRDF-develop mailing list
>dot...@li...
>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop