Re: Finding and Reminding, tech issues, 3.0 and beyond

Is it entirely true that RDF/Sparql, whilst giving us the power to model
stuff better, is harder to use and makes things more difficult to devs
who dont know it

I had always imagined there would be a client library that did not
expose RDF/SParql which would allow for more simple use and queries
(query by example or some simpler language). It would be much more
limiting than pure sparql but for the majority of apps where metadata
use is one dimensional it would suffice.

However it would be wrong to scrap RDF/Sparql as you could not model
links between resources nor interact as well with non-file cloud based
data. Also by utilising nepomuk ontology, we are benefiting from the
large EU investment in it and the refinements from Nokia/KDE which
ensure the ontology is application driven and not purely theoretical in

The apple metadata spec is one dimensional and could not be extrapolated
easily to model more sophisticated ontologies. Tracker 0.6 metadata was
like apples and it proved insufficient for the needs of Nokia and


On Thu, 2010-04-15 at 15:05 +0100, Bastien Nocera wrote:
> On Thu, 2010-04-15 at 13:05 +0100, Martyn Russell wrote:
> > On 15/04/10 12:32, Bastien Nocera wrote:
> > > On Mon, 2010-04-12 at 11:31 +0100, Martyn Russell wrote:
> > >> On 10/04/10 22:10, Owen Taylor wrote:
> > >>> On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote:
> > >>>> On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
> > >>> Well, certainly tracking and indexing file metadata doesn't *require*
> > >>> anything as complex, or general purpose as RDF. I have some concerns
> > >>> about the complexity, but as long as we don't get to the point where
> > >>> understanding RDF and ontologies is a prerequisite for developing a
> > >>> GNOME app, we're probably fine.
> > >>
> > >> I don't think this is such a bad thing. What other choices are there?
> > >> understanding how to extract the metadata from a specific file yourself
> > >> or understanding SQL to talk directly to a database? At least SPARQL is
> > >> something in between which provides the right level of power without
> > >> exposing the DB.
> > >
> > > And it ends up being neither. If you're manipulating file formats you
> > > understand, or if you understand the concepts and a library does the
> > > work for you, you're better off extracting the metadata yourself.
> > 
> > Are you? So if you have more than one application interested in the same 
> > data, that's still better off?
> > 
> > Plus what about the implementation, is it better to have n ways to 
> > extract the same data each one more/less featured/erroneous to the next 
> > or one place which does it and is maintained?
> My point was that SPARQL is neither a well-targeted API like that of a
> library, nor is it SQL (which people know, and hate), but somewhere in
> between.
> It's neither, and that means that you need to learn a new query
> language.
> <snip>
> > I couldn't this time last year either (and that's not a benchmark for 
> > how long it takes to learn either).
> I don't think your case is a good one, given that you worked on Tracker
> almost exclusively during that time.
> > > Better come up with good documentation before offering it to developers.
> > 
> > Well, other than the online docs we are constantly improving:
> > 
> >
> Huh. Go to that page, and find me the ontology that pertains to media,
> or contacts. The "big picture" is actually unreadable on my big
> (1680x1050) screen.
> > There is also the actual standard we try to follow:
> > 
> >
> At least that page has the TLAs exploded, and has more details about
> what each ontology does. Maybe it would be better to format this in
> gtk-doc style to replace the one on
> > If you're used to RDF of SQL, SPARQL isn't so difficult. There are also 
> > examples on the wiki:
> > 
> >
> Those seem like magic recipes. Again, it might be useful to have those
> available as helper functions, so they have vouched for and tested as
> part of your test suite.
> > Plus our code base is riddled with examples which have to work.
> > 
> > In addition to all this, we are on IRC to help too.
> > 
> > Bastien, if you think something else is missing, please tell us and we 
> > will try to fix it.
> Am I allowed to extend ontologies? What's the process for that? What
> happens if I want to store private data (something not covered by the
> existing ontology, say, the ASIN or MusicBrainz ID for music)?
> What pitfalls should I look for when I create queries? How do I deal
> with escaping in those queries?
> Where do I find information about the "big picture" of how all those
> things work together.
> Apple has a nice introduction that could be used as an example of what I
> would be expecting:
> Cheers
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]