So the goal is to support queries for resources based on constraints on properties e.g. find all Resources -> with the type foaf:Person -> the currentProject = Midgard ... That's a very important kind of query one can express with SPARQL (in general I think that most of the SPARQL queries one would need - in the CMS context - will be queries like that), but it is represent only a very small part of the SPARQL standard.
I am still unclear about the role of SPARQL in relation to "RDF in MidgardCR": - Do you plan to have a full SPARQL implementation - An partial implementation that supports a limited set of queries - An own query interface that is inspired by SPARQL - An own query interface that can also be implemented on top of SPARQL
@westei the plan is to take SPARQL parser from Tracker and connect it to our backend, eventually. we'll try to support as much of it as possible at that point. current state is "technology preview", not more.
indeyets
commented on
posted to #midgard
Aptekarskiy
16.12.2010
(en)
@westei MidgardCR is underlying storage, query language and programming language unaware, Content Repository. As @indeyets mentioned, it's technology preview. This example just illustrates how to query RDF data using SQL implementation which is built on top of proposed API. If anyone finds API usable and flexible, then might feel free to provide any implementation for any *QL language.
Maybe you should have a look at D2R-Server [1]. This allows to map relational schemas to RDF and implements also a SPARQL Endpoint on top of that. I know this is not exactly what you are try to do, but it may still give a lot of good input.
@westei Thanks for the info. I think we're doing almost the same thing, I mean mappings. Though, in MidgardCR mappings are more flexible and more powerfull IMHO. Take a look at this example. Our models (schemas) are created programaticaly. Of course, those do not map RDF to storage, but the point is that you can provides different storage models to the same object (class) model, and map RDF to objects or data on application level. This mapping is very nice, but limited in any sense IMO. I'll read more about D2R during the weekend. Any shared idea is appreciated and valuable :)
The Model API. IMO it doesn't make sense to map RDF (or any other metadata) to storage. In OOP we need to work with objects, so conceptually RDF should be mapped to objects and these should be mapped to storage. With this approach one object might be stored (and serialized) using unlimited numbers (and kinds) of storage. API itself doesn't focus on particular solution. Instead it gives you flexible way to map (and create relations) among persistent data, not persistent data and metadata.
