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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Thanks for your reply.

You know, there problem with dotNetRDF is that there are quite a few
classes with overlapping functionality and it does get quite
confusing.

Yesterday I have also again bumped into PersistentTripleStore, which
wraps an IStorageProvider. How does that work?

And what should I do? Wrap IStorageProvider with PersistentTripleStore
or wrap triple stores with a InMemoryManager. Are there some clearly
defined advantages and disadvantages?

Thanks,
Tom

On Mon, Sep 24, 2012 at 7:05 PM, Rob Vesse <rv...@do...> wrote:
> 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
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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