1. 03 Aug, 2018 1 commit
  2. 27 Jan, 2018 3 commits
  3. 16 Dec, 2017 1 commit
    • Sam Thursfield's avatar
      Rename libtracker-common to libtracker-miners-common · 3cee7b92
      Sam Thursfield authored
      We made a big compromise when splitting tracker core from tracker-miners
      in that the common code that was needed by both parts would end up
      duplicated. It's ugly but it works fine at the moment and allows us to
      keep all of the common code private.
      
      I had an issue when trying to embed tracker core into tracker-miners as
      a Meson subproject though. Having two targets named tracker-common
      caused confusion as duplicate targets aren't allowed, but they are not
      quite equivalent so we can't just pick one or the other.
      
      To work around this, I've renamed the copy in this repo to
      tracker-miners-common. This only affects the target names, not the
      actual function names.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=789725
      3cee7b92
  4. 20 Sep, 2017 1 commit
  5. 16 Jan, 2017 4 commits
  6. 16 Jul, 2016 1 commit
  7. 14 Jul, 2016 1 commit
    • Sam Thursfield's avatar
      Use TrackerResource instead of TrackerSparqlBuilder in all extractors · 8cc026da
      Sam Thursfield authored
      For a long time, all the Tracker extractors have manually constructed a
      SPARQL update command using TrackerSparqlBuilder to represent their
      output. This commit changes all of them to use the TrackerResource
      class instead, which makes the code a lot more concise and readable.
      
      This introduces some API breaks in the internal libtracker-extract
      library. This has been a private library since Tracker 0.16 or earlier,
      so it's fine.
      
      If the extractors only output SPARQL then they are only useful to
      people who are using a SPARQL store. Now we can output a serialization
      format like Turtle as well. This will hopefully make the extract modules
      useful outside of Tracker itself.
      
      I've tried to preserve the behaviour of the extractors as much as
      possible, but there are two things that are now handled differently:
      
        * nao:Tag resources are given a fixed URI based on the tag label, such
          as <urn:tag:My_Tag>. Previously they were inserted as blank nodes,
          so tracker-store would give them unique IDs like <urn:uuid:1234...>
      
        * All extractors created nco:Contact resources for content publishers,
          but previously some would assign fixed URIs based on the name
          <urn:contact:James%20Joyce>, while others would insert them as blank
          nodes so they would be assigned unique IDs like <urn:uuid:1234...>.
          Now, all extractors create nco:Contact resources with fixed URIs
          based on the content creator's name.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=767472
      8cc026da
  8. 13 May, 2016 1 commit
    • Julien Hémono's avatar
      IPTC extractors : use nco:contributor for contact metadata · a05758cd
      Julien Hémono authored
      5a27279a adds support for contact
      IPTC metadata and represents it with a nco:representative predicate.
      
      This contradicts the ontology that stipulates that the subject of
      a nco:representative predicate is a nco:Contact. Consequently, updates
      from extraction of files containing this IPTC field are rejected by
      the store.
      
      This fix uses the nco:contributor predicate instead. Official
      documentation at [1] says the field "Identifies the person or
      organisation which can provide further background information on
      the objectdata." Nco:contributor is therefore too narrow as not every
      such person need be a contributor. The adequate predicate doesn't
      exist but if it did it would definitely at least be a nao:annotation
      or more narrowly a nao:isRelated. But I deem these too broad because
      their range isn't a person or an organisation.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=762675
      a05758cd
  9. 14 Mar, 2016 1 commit
    • Carlos Garnacho's avatar
      tracker-extract: Use safer method to insert tags in JPEG module · 9153e5d4
      Carlos Garnacho authored
      The current way of inserting the nao:hasTag relationship on the
      extracted file involves one join operation per tag being inserted.
      This has performance implications, plus we can feasibly hit the
      sqlite limit of 64 tables in joins.
      
      Instead insert the tags in separate inserts, that will be as fast
      as it gets, plus there's no limit in the number of tags.
      9153e5d4
  10. 28 Jul, 2014 1 commit
  11. 19 Mar, 2014 1 commit
  12. 14 Dec, 2011 1 commit
  13. 28 Oct, 2011 1 commit
  14. 03 Oct, 2011 1 commit
  15. 22 Sep, 2011 1 commit
  16. 07 Sep, 2011 2 commits
  17. 06 Sep, 2011 5 commits
  18. 02 Aug, 2011 1 commit
  19. 10 Jun, 2011 4 commits
  20. 28 Mar, 2011 1 commit
  21. 24 Mar, 2011 1 commit
  22. 21 Mar, 2011 1 commit
  23. 15 Mar, 2011 1 commit
    • Carlos Garnacho's avatar
      tracker-extract: mass change extractors · f88855de
      Carlos Garnacho authored
      The API has changed, now the following function must be exported:
      
      gboolean tracker_extract_get_metadata (const gchar          *uri,
                                             const gchar          *mimetype,
                                             TrackerSparqlBuilder *preupdate,
                                             TrackerSparqlBuilder *metadata);
      
      This was done in one go as there's no painless way to do this...
      f88855de
  24. 16 Feb, 2011 1 commit
  25. 13 Jan, 2011 1 commit
  26. 11 Jan, 2011 1 commit
  27. 15 Dec, 2010 1 commit