Hi all,
Carlos recently worked on the hierarchical-indexing branch to ensure
parent directories are added to the database BEFORE files or child
directories. This avoids additional SPARQL calls and caching that would
otherwise be required when processing the crawled directories. So
essentially
Hi all,
I was planning on doing the release as usual tonight, but I have found
some regressions in the hierarchical-indexing branch which need fixing
before it can be merged to master. It also contains the fix for the
duplicate files appearing in the database issue which is the point of
the b
On 18/02/10 17:11, Martyn Russell wrote:
Hi all,
Carlos recently worked on the hierarchical-indexing branch to ensure
parent directories are added to the database BEFORE files or child
directories. This avoids additional SPARQL calls and caching that would
otherwise be required when processing t
Hi,
in the nmm ontology, we currently have nmm:leadActor, with a max
cardinality of 1. What should I do if I want to store more actors ?
Creating a "virtual" artist with a comma delimited name seems quite
hackish
:)
Cheers
Adrien
___
tracker-list ma
On Thu, 2010-02-18 at 23:07 +0100, Adrien Bustany wrote:
> Hi,
>
> in the nmm ontology, we currently have nmm:leadActor, with a max
> cardinality of 1. What should I do if I want to store more actors ?
> Creating a "virtual" artist with a comma delimited name seems quite
> hackish
Can you give
hi,
I think that property should have cardinality N. It looks like a bug
in the ontology.
On the other hand, nobody is using yet that property. Is anybody
working on a miner retrieving data from imdb? }:-)
ivan
On 2/18/10, Philip Van Hoof wrote:
> On Thu, 2010-02-18 at 23:07 +0100, Adrien Bu
hi Florent,
i have the impression that those properties are application
information. The color or key for a tag can be different in each
application,
i really like the use case of quick tagging using a key per tag, but
that relation should be handled on the "client" side, not in tracker.
regard
