Central tagging provider

[rtreffer]

Hi,

here is my idea for a content provider:

> Items (<content_uri>s)
> Tags (tuple of <name>,<parent_tag>,<weight>)

An Item can be linked to any number of tags. Actually "items" are just
tags with a a content url as a name. The item <-> tag relation
degenerates to a Tag2Tag relation.

It's *just* a centralized tagging/label library on top of a DB.

This is not very usefull by itself. I would like to add a query
language for tags, e.g. all items that have a label "Albums">"Eat me,
drink me", or fetch all "Albums"-tags that have items belonging to
"Favorites". Or all locations related to "work" and "data center".
Additionally the content provider could resolve remote content URI's
and allow retrieval of external content (e.g. retrieve locations by
tags instead of geo content uri's).

I've seen you have already suggested a geo tagging idea, but I don't
see a reason why it should be limited to locations/geo informations.
I'm personally interrested in using a tag provider for music tags and
navigation (favorites, custom menu layouts etc.)

Please tell me what you think about it and add me to the project if
appropriate.

Thanks in advance,
Treffer

SQL for that provider could look like:
> create table if not exists TAG (
> ID bigint primary key,
> PARENT_ID bigint DEFAULT NULL,
> NAME varchar(255) NOT NULL,
> ITEM boolean NOT NULL DEFAULT FALSE,
> WEIGHT double DEFAULT 1.0,
> FOREIGN KEY TAG(PARENT_ID) REFERENCES TAG(ID)
> ON DELETE CASCADE ON UPDATE CASCADE,
> UNIQUE(PARENT_ID,NAME)
> );

Queries could look like

content://tags/* (All tags, huge)
content://tags/+'Album'/*+'Marylin Manson' (All tags that are childs
of Album and that have an item tagged as "Marylin Manson")
content://tags/items/'Album'/'Eat me, drink me'/* (All items that are
tagged as Album/Eat me, drink me)
content://tags/items_resolved/'Eat me, drink me'/* (All items
resolved)

I'm still thinking about that. Especially about 'not', 'and', 'or',
'grouping' etc...

[NumBeast]

I was also thinking of a SQL database, and here's what I came up with:

 

There are three table, one to hold Data, one to hold tags, and one to hold mappings between the two.

The Data table has two columns: 1. The id 2. The geo URI

The Tags table has two columns: 1. The id 2. The Tag String

The Mappings table has three columns. 1. The id 2. The Data_id 3. The Tag_id, an entry in this table applies the tag referenced by the tagid to the data referenced by the data id.

 

The database will be asked for data matching given tags more than anything. So I'll explain how such a query would work. Say you want all locations that are tagged 'home' (we can discuss later if we should allow spaces in tag names, and how we plan on implementing that) and 'cali'. Your query string would look something like this: "content://org.openintents.locations/home/california" (We can debate the URI format later, but that's more or less independent of the system for storing location data) When it receives this request, the content provider would first look at the Tags table, search for the tag names, and remember the ids returned. It would then look at the Mappings table and search for all entries that use one of those tag_ids. It would then look up returned data_ids in the Data table and return the results.

 

I like this method because it is fast, simple, and extendable. I actually don't know if it's fast or simple, so please give me reasons why it is or isn't.

It's extendable because you can change the type of data in the tag string, allowing you to tag data with images, or music, or whatever you want. You can add another column to the Mapping table, allowing you to define the kind of relationship between the data and the tags. to take things even further, you can remove the concept of data, and turn the database into a relationship between tags. That would turn it into our own version of a RDF format. I'm only throwing out ideas, I'm not saying we should make a varient of RDF in our first version. I would like to see the database hold location data, and work, and make it fast. If we need to build another tagging system for another type of data we can build it. And I'd only be happy generalizing this system, and doing complex things with it, until we have a least three projects that could use it.

 

Feel free to respond and tell me what I'm messing up, over or under thinking.

 

On Dec 11, 2007 5:02 AM, rtreffer <rtre...@googlemail.com> wrote:

Hi,

here is my idea for a content provider:

> Items (<content_uri>s)
> Tags (tuple of <name>,<parent_tag>,<weight>)

An Item can be linked to any number of tags. Actually "items" are just
tags with a a content url as a name. The item <-> tag relation
degenerates to a Tag2Tag relation.

It's *just* a centralized tagging/label library on top of a DB.

This is not very usefull by itself. I would like to add a query
language for tags, e.g. all items that have a label "Albums">"Eat me,
drink me", or fetch all "Albums"-tags that have items belonging to
"Favorites". Or all locations related to "work" and "data center".
Additionally the content provider could resolve remote content URI's

and allow retrieval of external content ( e.g. retrieve locations by

[Peli]

Hi rtreffer and NumBeast,

I like your ideas a lot!

Since everything can be accessed by an URI (photos and videos via
content://media..., etc., web pages via http://, and of course there
is geo://) NumBeast's 3 table setup seems like a good choice: It
scales with the number of data items (1st table), the number of labels
(2nd table), and the number of connections between them (3rd table).

One immediate question is: Android already stores label information
with contact data for example. How should they be synchronized?
Probably that is also not such a big deal, as there is a way to get
notified when data change.

As for the relation, I like labels so much, because they do not impose
a strict directory structure, like directory paths do. On the other
hand, I think more than one label can be interpreted much better than
just saying it is in both groups.

Having something labelled "home, letter" could either be displayed as
home / tool
home / software
home / letter <-- here is the item
work / tool
work / software
work / letter

or organized as
tool / home
tool / work
software / home
software / work
letter / home <-- we can also find it here
letter /work

(instead of doing it as it is done currently with Google bookmarks:
you find it in "home" (that contains all home-tagged items) and in
"letter", making both lists long and uneasy to search through.)

A final twist: what if we give labels also their own URI? In this way
one automatically can build relations between labels.
"home" and "work" are then tagged "location", for example. Labels
could be organized in groups.
"home" and "work" could further be tagged "favorite", and this would
automatically mark them as favorite.

URI suggestion:
content://org.openintents.label/name/home
(this is an URI for the label "home")

(in the database, it would probably be more efficient to introduce a
fourth table with three columns: 1. id, 2. tag_id_1, 3. tag_id_2, The
tag_id_1 is instead of a data_id where the data simply contains an URI
to the label tag_id_1)

What do you think?

Peli

[Peli]

To extend on the last idea, this could probably also solve the
question of localization:

There are system-tags: e.g.
oi:work
oi:home
oi:school
oi:favorite

But users can use their own labels in their own language
"work", "Arbeit", "Lavoro", ...
As long as they are tagged "oi:work", the system knows how to
interpret them.

If one spends part of the time with the parents, and part of the time
at university dormitory, even several labels could be tagged
"oi:home":
"dormitory" (tagged "oi:home")
"parent's house" (tagged "oi:home")

The system tags should be hidden. This could be easily managed by
tagging all of the above system tags as oi:system.

Then, oi:system would be tagged by itself in a useful way. Pretty
neat, right?

We can still discuss about the shape of system tags.
In order to avoid any future conflict, they should probably contain
the domain in some way.
The question is whether to use full URI notation, or some
abbreviation? In the long run, it probably pays to use a consisten URI
scheme, although it is longer. For the end user, the system tags
should anyway never be visible directly:

content://org.openintents.labels/system/home (abbreviated above as
"oi:home")
content://org.openintents.labels/system/work
content://org.openintents.labels/system/school

Peli

[Peli]

Probably one could add one more table, to avoid all the lengthy
strings when storing URIs and tags with long URIs:

Namespace: 1. id, 2. generic URI
This could contain
1 "content://org.openintents.label/user"
2 "content://org.openintents.label/system"
3 "geo://"
4 "content://media/photos"
...

Then the data tables and tag tables would get each a third entry:
data: 1. id, 2. namespace, 3. last_URI_part (e.g. 1, 3,
"-1.234,2.345")
tag: 1. id, 2. namespace, 3. last_label_part (e.g. 1, 1, "myhome")

It is some additional overhead, but it would reduce redundancy when
storing strings.

Would this make queries too complicated? Could there be additional
trouble introduced by such a five-table system, or is it better to
reduce the number of tables required?

Peli

[rtreffer]

On Dec 11, 10:02 pm, NumBeast <numbe...@gmail.com> wrote:
> I was also thinking of a SQL database, and here's what I came up with:
>
> There are three table, one to hold Data, one to hold tags, and one to hold
> mappings between the two.
> The Data table has two columns: 1. The id 2. The geo URI
> The Tags table has two columns: 1. The id 2. The Tag String
> The Mappings table has three columns. 1. The id 2. The Data_id 3. The
> Tag_id, an entry in this table applies the tag referenced by the tagid to
> the data referenced by the data id.

Yes, this was my first idea, too. BUT: what *kind* of content would
you like to store? Anything should be taggable, which means there is
no content except a URI/String. That's why I said there is no reason
for a Item/Content table.

There is a need for hirarchical tags, e.g. if you want to group your
work locations by cities. Or your favorites by colors.

My idea was to flatten tag hirarchies. You can have
Favorite Locations > green > geo://y
but you'll have relations
geo://y <> green
geo://y <> Favortie Locations

But you can also retrieve all TAGS that are Favorites (making 2-level
browsing easier)

My design isn't perfect either. I'm trying to make music tagging
possible, which is more compicated than geo tagging (in terms of
tagging, not in terms of location based searching). I've problems e.g.
with double albums (think about Stadium Arcadium or Mezmerize/
Hypnotize) and retrieving (should be simple and powerfull). My
intention was to browse Artist > Album > Songs with tags (or any other
order).

@Peli: Namespaces itself could be tags.
@Peli: are you thinking flat (work + tool) or hierarchical (work/
tool)?
@Peli: tagging of tags is cool. I though a simple hierarchie would be
easier to manage and faster to search
@NumBeast: I'd actually like to use it for music so there might be a
need for generalization. I'd like to centralize all tagging
@Peli: tagging tags makes searches extreme complex and slow. But it
could be flattened.

Finally what do you think about chained retrieval? Aka the tagging
content provider will provide geo coordnates instead of geo:// URI's
e.g.
content://org.openintents.label.resolved/name/home
could retrieve geo information instead of geo URI's.

@All: Shouldn't we setup a wiki page about the idea? Have you looked
at the voting on other Android projects?

[flowdi]

Hi everyone,

this seems to take of here
I like the ideas so far :) very inspiring!

@NumBeast: I fully agree with 'keep it simple' as long as it's not
necessary
but we are already four people needing 'tagging' so lets think about
generalising :)

every thing is taggable through a central generic taggingprovider
the content is stored (provided) elsewhere (in the contentproviders)
the tagging provider just stores the tags themselfs and the taggings.
the tagging table simply maps tag_ids to item-uris?
(the latter already contains the content-type and can as well point to
a tag again)

what about:
- an activity: intentreciver for action:'TAG_IT'
given a content uri (the item to tag) brings up a gui to select tags
or create new ones (tag it).
- an activity: intentreciver for action: 'VIEW'
given a contenttype brings up a gui to browse tags / related tags /
hierarchies
and the corresponding items can be selected (for returning after a
subactivity invocation)

the android-labels become redundant - synchronizing is complicated
but could be used as index to speed the 'tagged_with'-listing of items
every tagging updates (pushes) a comma-seperated string in the label-
column of the actual contentprovider
did you get what I'm trying to explain?

tags of tags
as Peli mentioned tags/labels should themself be referencable through
an uri
so tags are just another content and thus taggable which allows for
the explicit statement of real hierarchies (taxonomies) much more
powerful than e.g tag-bundles at delicious.

@Peli: did I get you right?
oi:system-tags are some kind of roots for hierarchies?
and / or common predefined tags (everybody will need)?
users can make alias-tags in their own language (e.g. 'Arbeit' for
such common tags like oi:work)
that would help translating synonyms (different words for the same
concept) between users

store everything flat (like rtreffer suggested) defenitly makes sense.
should speed up queries

what is the difference between a AND-search and browsing a hierarchy?
(is it just that the latter is unidirectional? tools/home not the same
as home/tools)
can hierarchies (trees) also be implicitly detected without the need
to state them explicitly?
(i.e. tagging tags explicitly - a parent-child-relation)

random thoughts:
..or just a simple plain tag-graph (without root-tags) that is
browsable like a hirarchy (related -> related -> related -> ..
..are tagclouds useful? on small screens? or rather confusing
..could the tagging-work be shared? e.g. 'a lot of people tagged this
place as 'party''
or browse places my friends from the phonebook tagged as 'party'
..there are many websites triing to collect 'tagged locations' as user
generated content
does it make sense to interface with such backends?

What do you think?
pleas "Feel free to respond and tell me what I'm messing up, over or
under
thinking."

[Peli]

rtreffer,

> here is my idea for a content provider:
>
> > Items (<content_uri>s)
> > Tags (tuple of <name>,<parent_tag>,<weight>)

Ok, now I see your point that tags are just like URIs, so no need for
two tables, only one. You stated what I repeated afterwards in a
complicated way, but I didn't understand in your first post.

What is "weight" for? What did you have in mind here? You tag you
"pizza hawaii" just "20% favorite" and "pizza cappriciosa" "40%
favorite"?

The other thing about namespaces was just meant for internal use, to
reduce memory taken redundantly by taking apart long URIs where only
the last few characters change. I have no idea whether splitting
things up would reduce memory or just decrease speed due to overhead.
But this would in any case be an "under the hood" optimization (if at
all) that can be kept in mind for later.

Thanks for setting up the Wiki page. As for the voting process, I
expect more members over the next few days, so i wonder whether
swapping columns and rows would not be more readable in the near
future (I'm being optimistic :-) )

[rtreffer]

On Dec 12, 6:45 pm, Peli <andreas....@gmail.com> wrote:
> rtreffer,
>
> > here is my idea for a content provider:
>
> > > Items (<content_uri>s)
> > > Tags (tuple of <name>,<parent_tag>,<weight>)
>
> Ok, now I see your point that tags are just like URIs, so no need for
> two tables, only one. You stated what I repeated afterwards in a
> complicated way, but I didn't understand in your first post.

Sometime ideas need to be explained in different ways. It's very hard
to explain an idea in an easy way, especially if you have thought
about it for some time, I think it's my fault, as I'm not able to
simplify it to a point where every one can understand it. Sorry, but
it's great if we can agree on that *g*

> What is "weight" for? What did you have in mind here? You tag you
> "pizza hawaii" just "20% favorite" and "pizza cappriciosa" "40%
> favorite"?

Weight was an idea to allow algorithms to detect important and
unimportant tags. I don't insist on this anymore, but most tag-clouds
use weights (bigger and smaller text). I thought it might be usefull
to push this into the DB, but I'm not sure about it. I would suggest
to leave it out untill we have a real use case. I should have striped
it out.

> The other thing about namespaces was just meant for internal use, to
> reduce memory taken redundantly by taking apart long URIs where only
> the last few characters change. I have no idea whether splitting
> things up would reduce memory or just decrease speed due to overhead.
> But this would in any case be an "under the hood" optimization (if at
> all) that can be kept in mind for later.

I would save them as flat URI's. The "overhead" isn't that big. And
keep in mind that there is a index over the items. Namespaces would
help to simplify queries like "I'm looking for locations". "Keep it in
mind for later" sounds reasonable. I wouldn't care about storage as
tagging is a low storage overhead compared to the actual date (I guess
much less than 100% overhead, depending on the data type, e.g.
geographic tagging might cause 100% overhead, music tagging will cause
<1% overhead)

Anyway I don't thing speed would be an issue unless you store several
MB of data. I've noticed a considerable slowdownn with amarok + >50GB
music tags in sqlite, but I don't expect every phone to have a 200GB
HD.

I really like flowdi's idea of an "tag it" action/intend. You can
initiate tagging from any app for any content and you'll simply get a
tag-cloude. This is quite simple and really usefull. Sounds like a
good idea.

> Thanks for setting up the Wiki page. As for the voting process, I
> expect more members over the next few days, so i wonder whether
> swapping columns and rows would not be more readable in the near
> future (I'm being optimistic :-) )

Anything that improves communication is good. Would you like to
initiate #openintents on irc?

I thought about swapping columns, but I guess there will be ~1 idea/
person and most persons will vote with yes/no. The idea was stolen
from http://code.google.com/p/geagle/wiki/gEagleFeatures (I didn't
have the time to google for it). I'd suggest this for most ideas (at
least those ideas that get 3+ devs)

s the right place to implement it or is openintends the right place to
suggest/specify it?

@NumBeast: What do you think? I'd really like to talk to you. Feel
free to cantact me via pm or whatever else suits your needs.... I
don't want to annoy you or kick you out in any way....

[NumBeast]

Sorry for the lack of communication, it's amazing how much I can miss by being gone for 20 hours. Unfortunately finals are coming up, and I'm not going to be useful for deep thought until saturday at the earliest. But to throw a few things out:

Last night I got tierd of talking about things, and tried to start coding something up to show you guys. To cut it short, I got nowhere worthwhile. I'm currently combing through all of google's documentation to figure out how to make a functional ContentProvider. An example problem... What's the MIME type of geo:// ?

P.S. I read all of your emails and wrote up quite a bit about them. Unfortunately most of it is nagative, parts of my response contradict itself, and it's pretty hard to read. I'll put it all together into a coherent form and e-mail you guys later.
Quick Summary: "Keep it simple, don't generalize too early, keep to the spirit of tagging (no heirarchies)"

Hope to write to you soon, Thanks for all the great ideas to slowly devour, digest, and enjoy. I can't wait to see how OpenIntents ends up. 

[rtreffer]

On Dec 13, 7:59 am, NumBeast <numbe...@gmail.com> wrote:
> Sorry for the lack of communication, it's amazing how much I can miss by
> being gone for 20
> hours. Unfortunately finals are coming up, and I'm not going to be useful for
> deep thought until saturday at the earliest. But to throw a few things out:

I regard nothing as final. It's my brain dump by now, feel free to add
your thoughts.

> Last night I got tierd of talking about things, and tried to start coding
> something up to show you guys. To cut it short, I got nowhere worthwhile.
> I'm currently combing through all of google's documentation to figure out
> how to make a functional ContentProvider. An example problem... What's the
> MIME type of geo:// ?

What do you mean by MIME type of geo:// ? Should an URI have a MIME
type?
The best mime type (according to /etc/mime.types) might be text/uri-
list - but mime is for content and not uri's afaik....

What did you try to code? svn ci to test?

> P.S. I read all of your emails and wrote up quite a bit about them.
> Unfortunately most of it is nagative, parts of my response contradict
> itself, and it's pretty hard to read. I'll put it all together into a
> coherent form and e-mail you guys later.
> Quick Summary: "Keep it simple, don't generalize too
> early, keep to the spirit of tagging (no heirarchies)"

It took me a night to think about it, and I would suggest to go for a
flat system first (0.X, <=1.0). It's easier to get it right and
anything else should be left out for a 1.0 or 2.0 version. A flat
tagging system should be easy to implement and use. KISS [1] sounds
good.

[1] http://en.wikipedia.org/wiki/KISS_principle

[friedger]

I have added a draft of the table description in
http://code.google.com/p/openintents/wiki/CentralTagging
Does this makes sense so implementation could be started?

[friedger]

I am now waiting for an activity that
accepts

ContentURI uri = Locations.CONTENT_URI;
uri.addId(id);
Intent intent = new Intent(TAG_ACTION, uri);

Friedger

On 13 Dez., 12:41, friedger <fried...@googlemail.com> wrote:
> I have added a draft of the table description inhttp://code.google.com/p/openintents/wiki/CentralTagging

[Peli]

Hi friedger!

Wow, that is some boost and tempo added to the project. Unfortunately
right now I don't have time to review your work so far, but I
corrected the table on the wiki page according to what I think was
rtreffer's clever suggestion, so that you are not hindered to continue
your inspiring progress!

http://code.google.com/p/openintents/wiki/CentralTagging

I'm really excited! :-)

[rtreffer]

On Dec 13, 2:19 pm, friedger <fried...@googlemail.com> wrote:
> I am now waiting for an activity that
> accepts
>
> ContentURI uri = Locations.CONTENT_URI;
> uri.addId(id);
> Intent intent = new Intent(TAG_ACTION, uri);
>
> Friedger

Yes, that's what I'm looking for, too. The cool thing is Intents can
be transparent and overlap with the intent sender.
A "tag this" intent would just feel like a native app feature

So you can just throw an URI and say "tag this for me" and noone will
notice it's a different app :)

[friedger]

I agree with the changed table definition.

Re tags/labels have content_uri:
If this is the case we also need a tag provider that resolves the tag
content uri into a tag name. Isn't that overdone?

Friedger

[rtreffer]

On Dec 13, 8:14 pm, friedger <fried...@googlemail.com> wrote:
> I agree with the changed table definition.
>
> Re tags/labels have content_uri:
> If this is the case we also need a tag provider that resolves the tag
> content uri into a tag name. Isn't that overdone?

No, you are free to store either content uri's, readable names, or
whatever else suits you.

The fun about content_uri's for labels is you can use images as
labels, or audio files. Anyway a content_uri is a String, just like a
text. It should be more like "you can use content_uri's as labels,
too".

I wouldn't suggest it right now, but for a future release. I'll update
the wiki about the idea.

[friedger]

Ah, yes I got it now.
Friedger

[Zero]

not sure if i should reply here or in the other thread, but i'm
wondering why there is such a thing as content table. instead of
storing content_id in the tab table, you could store content_uri
directly. keeping track of additional id's might be troublesome.

great project, by the way.


Zero

[Peli]

> instead of
> storing content_id in the tab table, you could store content_uri
> directly.

In principle you are right. If every content_uri only exists once,
there is no point in introducing ids. The idea is, that one may have
more relations between contents and tags, and then it would pay to
define these via LONG than STRING. Also searches for same tags could
be quicker if one just needs to compare numbers instead of long URIs

> great project, by the way.

Thanks

[Zero]

On Dec 14, 11:26 pm, Peli <andreas....@gmail.com> wrote:
> Also searches for same tags could
> be quicker if one just needs to compare numbers instead of long URIs
>

point taken. :)

i suggest adding the (obvious?) tags
content://org.openintents.tags/system/business
content://org.openintents.tags/system/personal (or private?)

to the list.

somehow i get the feeling that the ability to tag everything might be
the one major feature of the platform. so, count me in :)

[friedger]

Yes, tagging everything will be a great feature of the plattform.

For now, we don't have a uri for tags like
content://org.openintents.tags/system/business

If we want a uri for standard tags I would suggest a different scheme
tag://system/business

"content://" is IMHO reserved for content of a data base (or similar).
Friedger

[Peli]

Friedger,

I agree with you now. If we are to extend the content table by a third
field, then this could indicate system labels: kind = URI, TAG, or
SYSTEMTAG

content table
_id | URI or string | kind
1 | http://www...... | URI
2 | My cave | TAG
3 | home | SYSTEMTAG
4 | business | SYSTEMTAG
...

Peli

[Peli]

Thinking about it a bit more, the number of system tags is probably
quite limited, and they should have some special meaning to the
programs. Then it would make sense to indicate the type of the system
tag in the third column:

content table
_id | URI or string | kind
1 | http://www...... | URI

2 | Visit to Paris 2005 | TAG
3 | home | TAG_HOME
4 | business | TAG_BUSINESS
5 | My cool stuff | TAG_FAVORITE
6 | content://media/images/34 | URI
7 | content://org.openintents.shopping/items/17 | URI

with URI=0, TAG=1, TAG_HOME=2, TAG_FAVORITE=3, ...

Now (6,5), (7,5), and (7,4) would mean that image #34 and item #17 is
part of my favorites, and item #17 is furthermore business related.

Of course, critics (rtreffer) will say that the relation (My cool
stuff, TAG_FAVORITE) is one that should move also into the relations
table, and one should really store:
_id | URI
1 | content://org.openintents.tags/system/3 (which contains
"TAG_FAVORITE")
2 | content://org.openintents.tags/user/29 (which contains "My cool
stuff")
3 | content://media/images/34

and the relations table contains (2,1) and (3,2) to indicate that
image #34 is part of the favorites. But I think this would be too much
of abstraction. (Note that only one relation, e.g. (6,5), is needed in
the first case to mark something as favorite, as opposed to two here:
(2,1) and (3,2)) The immediate needs are to have a handful of special
meaning tags that should be searchable through efficiently, and user
adjustable / localizable

From an abstract and functional point of view, both approaches are
actually equivalent, but I think the former one is closer to the needs
and possibilities of a small phone.

rtreffer, do you agree?

Peli

[friedger]

I like the idea of a third column
Friedger

[Peli]

Great. For now, let us concentrate on the KISS features: I've updated
the wiki page for central tagging:
http://code.google.com/p/openintents/wiki/CentralTagging

and wrote a release plan:
http://code.google.com/p/openintents/wiki/ReleasePlan

According to which the simplest approach is fine enough for 0.1.0. Do
you agree with this?

Peli