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

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

It's neither, and that means that you need to learn a new query

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


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