Re: Proposing Tracker for inclusion into GNOME 2.18
- From: "James Henstridge" <james jamesh id au>
- To: "Jamie McCracken" <jamiemcc blueyonder co uk>
- Cc: Ross Burton <ross burtonini com>, desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Proposing Tracker for inclusion into GNOME 2.18
- Date: Tue, 24 Oct 2006 23:26:33 +0800
On 19/10/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
Ross Burton wrote:
> Also, if I search for "created by ross" how does the system need to know
> that it should search File.Publisher, Audio.Artist, Audio.Performer,
> Doc.Author and Image.Creator? The naming scheme here is inconsistant
> and redundant.
If we were a dedicated search tool then yes but we are a metadata DB as
well so we need specific metadata names as Audio.Artist and
Aduio.Performer can contain different values and we might want to only
search one of those fields.
I think that the idea Ross is trying to get across here is that rather
than having a flat namespace of metadata types, you want to have
relationships between the metadata types (metadata about metadata).
For example, we might have a have a relationship that says that "ross
performed song.ogg" is a specialised version of "ross created
song.ogg". Another simple relationship between metadata types might
be that "ross created song.ogg" implies "song.ogg was created by
ross".
The idea is that these implicit relationships would be used in
queries, so if we have the relationship "ross performed song.ogg" in
the database, then song.ogg will be picked up by the query "files
created by ross". At the same time, the file would not get picked up
by a query for "files photographed by ross".
This is particularly important in a system with an extensible metadata
system. If app developers can introduce arbitrary new metadata types,
it would be nice to know how they relate to other existing types.
As another example, consider a developers experimenting with a new
class of application. Lets say that two projects define some metadata
types for the files that they produce respectively. These types will
be distinct (hopefully there is something in the spec for namespacing
custom metadata), but a user might want to search both types of
documents.
So it would be nice if the metadata query system could be told that
sets of metadata types are equivalent. If the apps mature and agree
on a common set of metadata types, they'd probably want to include
mappings between the new standard types and the legacy ones.
James.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]