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

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

Nothing to add there really. Only that maybe you could share the
documented changes you plan for the next releases or maybe made it
public for discussion on the group.

I will be be happy to work on the fluent queries as I will be needing
it more and more for the LINQ implementation. I should refactor the
interface the way I mentioned earlier during the weekend.

Good night ;)
Tom

On Thu, Sep 27, 2012 at 10:05 PM, Rob Vesse <rv...@do...> wrote:
> Comments inline
>
> On 9/25/12 4:37 AM, "Tomasz Pluskiewicz" <tom...@gm...>
> wrote:
>
>>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.
>
> Yes, not every problem needs a hammer but also a lot of problems need ever
> so slightly different hammers
>
> Right now I'm focuses on getting to a stable 1.0 with only adding minor
> features (such as the fluent query API) which I'm aiming to do fairly
> rapidly with 4-8 week release cycles up to 1.0
>
> Beyond that anything is fair game, I have a lot of ideas floating around
> my head about how I'd restructure things if I had the chance to do a major
> refactor (think lots of significant breaking changes) and I'm getting
> towards the stage of writing that up into a design document.  This
> includes simplification and modularization of the API, memory footprint
> reduction, code deprecation and clean up etc.
>
> My thinking is likely that after 1.0.0 I will start a 1.9 branch which
> will be where the major refactoring takes place and maintain the default
> branch as bug fixes and minor feature for the 1.0.x series of releases.
> Once the refactoring in 1.9 is sufficiently done I'll start making
> parallel beta releases of 1.9.x and once that is sufficiently stable and
> tested we can merge that back into default, bump the version to 2.0 and
> release.  Parallel to 1.9 as things start getting removed/changed in the
> 1.9 branch we'd be updating the 1.0.x releases to mark the things that
> will disappear in 2.0 as deprecated so users who are interested can try
> out 1.9 with fore knowledge of what the breaking changes are.
>
>>
>>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?
>
> A PersistentTripleStore is an in-memory cache of some underlying triple
> store with the ability to enforce some level of transaction support on
> changes that happen in-memory.   Disadvantages is that it requires you to
> hold data in memory to make changes, advantages are the transaction
> support and the use of the more user friendly ITripleStore API.
>
> Rob
>
>>
>>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
>>
>>--------------------------------------------------------------------------
>>----
>>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
>
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> dotNetRDF-develop mailing list
> dot...@li...
> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop