Re: [Tracker] Extracting the extractors

I think this is ready now, I've created https://bugzilla.gnome.org/show_bug.cgi?id=767472 to track it. I'm around until July 16th to fix problems with it, then I'm away until September. So best to either review & merge this soon, or punt it til September. Sam On Mon, May 9, 2016 at 2:25 AM,

Re: [Tracker] Extracting the extractors

Hey Sam :), On Mon, May 9, 2016 at 1:40 AM, Sam Thursfield wrote: > I've made quite a bit of progress on this. The code is mostly there, > but i've only done a light amount of testing so far so there will be a > butt load of hidden regressions no doubt. > > I have a couple of

Re: [Tracker] Extracting the extractors

I've made quite a bit of progress on this. The code is mostly there, but i've only done a light amount of testing so far so there will be a butt load of hidden regressions no doubt. I have a couple of open questions: - is it OK to remove API from libtracker-extract ? I seem to remember that

Re: [Tracker] Extracting the extractors

Hi guys, Note to Sam and Cosimo that if his becomes a API used by external users, that it will in time have to follow API rules. These include not only not breaking API unless incrementing the major version numbering (which is something you shouldn't do every other week) but also things like

Re: [Tracker] Extracting the extractors

Hey Sam, A little late on this thread, but this sounds awesome! We actually chose JSON-LD too to represent record metadata for our offline content applications at Endless and I would be really happy if we could start using the Tracker extractors instead of rolling our own to extract metadata. I

Re: [Tracker] Extracting the extractors

On 09/04/16 00:39, Sam Thursfield wrote: Hi all Hi Sam, :) I've always felt like Tracker's extractors should be reusable outside Tracker. The design makes that possible but right now they output their results as a series of slightly non-standard SPARQL update commands, which I don't think is

Re: [Tracker] Extracting the extractors

On Mon, Apr 11, 2016 at 2:06 PM, Philip Van Hoof wrote: > As said, it's fine to add an output format for tracker-extract, but > between the processes tracker-extract, tracker-miner-fs and > tracker-store there's absolutely no need, whatsoever, to have JSON. Completely

Re: [Tracker] Extracting the extractors

Hi Sam, So, what happens when I read a blog like this, and I find this: Decision 3: Kick RDF in the Nuts RDF is a shitty data model. It doesn’t have native support for lists. LISTS for fuck’s sake! The key data structure that’s used by almost every programmer on

Re: [Tracker] Extracting the extractors

Thanks for the quick feedback! You're right that I should have implemented Turtle output. I've done that now, this is the result (as you'd expect): nmm:artistName "Best Coast" ; rdf:type nmm:Artist . nmm:albumTitle "The Only Place" ;

Re: [Tracker] Extracting the extractors

Hey Sam :), On Sat, Apr 9, 2016 at 1:39 AM, Sam Thursfield wrote: > Hi all > > I've always felt like Tracker's extractors should be reusable outside > Tracker. The design makes that possible but right now they output their > results as a series of slightly non-standard SPARQL

Re: [Tracker] Extracting the extractors

Hi Sam, The way to transfer metadata over a well defined standard way is called Turtle (TTL, https://www.w3.org/TR/turtle/). SPARQL is a query language that utilizes portions of this spec (with SPARQL INSERT you can more or less put a TTL block inside of INSERT{} and it should just work. Our

[Tracker] Extracting the extractors

Hi all I've always felt like Tracker's extractors should be reusable outside Tracker. The design makes that possible but right now they output their results as a series of slightly non-standard SPARQL update commands, which I don't think is useful for many folk. Lots of people aren't using SPARQL