Idea Favorite locations

[peli]

Hi NumBest,

Let's continue the discussion here, so that other people may also
follow. We can then put the results of our discussion to:

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

First of all: let's try to keep the design as simple and
straightforward as possible, but to start with, I'll write down some
random ideas:

I've seen that geo://0,0?q=... could support adresses, so one
possibility is to overwrite Google's contentprovider, so that instead
of a street address, one could also add "home", "work", or some other
favorite place... so this is a possibility.

The URI for the ContentProvider could be:
"content://org.openintents.favorites/locations/"
"content://org.openintents.locations/favorites"
"content://org.openintents.locations/"

Which fields do we need and how do we call them?
- geo (the coordinates)
- label (one or more labels)
- address (optional, street address)
- notes (arbitrary text)

How do you intend to include the security issues you suggested?

If you have any answers to any point, answer, and we'll go step by
step.
In the mean-time I'll set up the Android applications framework so
that we can start coding soon.

Peli

[peli]

I've seen that on the first table in http://code.google.com/android/devel/data/contentproviders.html
there are labels used for specific locations. These labels "California
office", "NY apartment", .. already serve as "favorite locations", so
probably there is no need to store separate information.

A simple ContentProvider could perform the following actions:
* provide a list of all labels
* for a label find one (or more) geo positions.
* for a geo position find one (or more) labels.

I think this would be the quickest start. I think Google's philosophy
is to give labels to everything. Then our ContentProvider should be
extensible to handle labels of all kinds of data, like images, and so
on. Then one could form groups, like connect certain images to a
certain person by giving them all the same label. A ContentProvider
will find all labels used, provide all system-wide items with a
certain label, or can system-wide rename or remove labels.

We don't have to implement this now, but the URI should reflect this
way of thinking somehow...

What do you think?

Peli

[flowdi]

a common location contentProvider to organise favourite locations
would benefit a lot of applications.
http://www.anddev.org/mini-google_map_including_source-t195.html
may be a good start..

could thes labels be used like 'tags' in folksonomies?
to categorize classify and order items...

if any kind of application (e.g. a browser) detects some kind of
adress-like text or even a geo-microformat it could fire an intent
with 'ADD_TO_MY_FAV_LOCATIONS'-action to launch an activity to label /
tag and save this place to the bookmarked locations...

flo

[NumBeast]

I like that idea. instead of naming locations, we can simply tag them. you could pull up all locations with a certain tag, quickly add a location by tagging it. The question then would be should OpenIntents define tags that can be used by all applications.

The URI for such a system could look exactely like a heirarchical file syste,
     content://org.openintens.locations/home would return all locations tagged with home
     content://org.openintents.locations/favorites/parks would return all locations tagged as a park in the list of all favorite locations.

[Peli]

Yes, I agree: This is the best to start with:
content://org.openintents.locations/favorites

I just wonder.. where do you intend to store the list of all favorite
locations? Should this be yet another ContentProvider that just stores
favorite tags and labels?

content://org.openintents.favorites/labels

So one can put labels into a favorite "folder" regardless of what the
label is intended for (eg. location, person, image, ...). What do you
think?

Extensions to keep in mind:
content://org.openintents.locations/home
content://org.openintents.locations/recent (recently used)

[Peli]

Flo,

I think Google "labels" (the same as "tags") are a very powerful but
simple concept. They become powerful if one could add the ability to
search through the labels or organize the labels in different
directory structures.

I just wonder.. so far we connect labels to addresses that are linked
to some contact. What about addresses that are not linked to a
contact? (Some spot on a map or some geo:// tag in a browser)

Does this mean that after all we have to create a new data table for
addresses that do not belong to a contact?

Let's keep this in mind for later, I guess...

Peli

[flowdi]

'Tagging' seems to be such a functionality (component) that would be
needed by a lot of applications.
(thus openintents is the right place to implement this together ;))
Every users creates her/his personal tagging 'sheme' (classification
system)
the same tags could be useful to tag locations, contacts, music,
pics...
a common TaggingContentProvider would make sense?

What do you think?

content://org.openintents.locations/home
content://org.openintents.tags/locations
content://org.openintents.locations?tags=home,recent,cool

a dedicated tagging-provider could be used to browse/navigate ones
personal taxonomy (classification system)
e.g. in some lbs-app one could launch the 'browse/select-tags-
Activity' of the common taggingprovider (as subactivity), return with
a selection of tags and then fetch matching 'locations' from the
common locationprovider (the search-results..)

is this too mauch mashing?
does it make sense to use the same labels to categorize different
content-types?
is there a more elegant android-way to achive this?

[NumBeast]

Let's define a few things before we start coding.

The goal of the project is (correct me if you think differently) to create a ContentProvider that allows applications to access a common list of locations and thus freeing the user of giving address data to each app.
I think the way to do this is by attaching tags to each location, and then allowing the applications to search only for all locations they want. We could even define permissions that allow users to provide fine-grained control over which applications can access which locations.

Regardless of implementation, we should also define some common tags. Like OI:home, OI:work, so applications know what to query for outside of data they put in.

I think this could be implemented as a database, like rtreffer suggested. But I'm thinking of organizing it differently.
One table for the tags, a column for the id, and a column for the tag name. another table for geo locations, again just an id and a location. 
And then a third table for the mappings. it's columns would contain the required id, the id of the data it's referencing, and the id of the tag applied to it. 

I'll write another email talking aout the URI soon.

[Peli]

Hi flowdi,

I fully agree: Everything that can have an URI should be tagable.

A tag could be "paris", and our Intent (that we still have to design
and specify) could give back all things that are tagged "paris", like
contacts living there, photos and videos taken there, locations,
notes, whatever..

It seems the technical discussion on this shifted to a new discussion
thread:
http://groups.google.com/group/openintents/browse_frm/thread/835348923f088608/2ac37c51073d7662

Peli