How do we integrate with 3rd party data formats?

Ted is creating a Flickr data entry parcel and asked about the best way to model this given our design proposal for extensibility:

Today's Flickr parcel is read only, but I'd like to make it a data entry parcel as well. Morgen has added an Import Photo item to the File Menu, which imports a generic photo. What I'm imagining doing is stamping that photo as a Flickr photo, which would add the fields needed by flickr. Then I could push a button somewhere and have the photo get uploaded. The things to think about are, how do we add the stamp icon for a Flickr Photo into the markup bar (or some other place or whatever). Also is stamping the right metaphor for this?

In the short term, we will probably just add another Flickr Kind to the Appbar and Flickr stamp to the mark-up bar, but in the long-term, I think we will need a more nuanced solution...

Here's a proposal:

I think this use case brings out the need for essentially a 3rd way of classifying Attributes...

For any attribute: (ie. Creator, Author, Date created, etc.), there's where does this attribute live in the Attribute hierarchy? Is it a Who, What, When, Where, Status or Value attribute?

There's also, what Kind or Stamp does this Attribute belong to? Communications>>Email, Media>>Photos, Directories>>Product catalog

Finally there's file format...We're sort of running into this already with Email. We want to map the From: attribute in an email to the From: attribute in Chandler, but I think ultimately we want to keep these two attributes as separate attributes because there are things we want to be able to allow users to do (ie. edit the From: attribute) that Email isn't generally set up to do.

So for a Flickr extension...there are presumably going to be bunch of Flickr specific attributes that might or might not map well to Chandler attributes? Creator, Tags, etc...

Non-proliferation Treaty for Stamping

I think we still only want to have a single Photo stamp...and users need to invoke some kind of separate Export tool to do the translation work necessary to get Chandler photos into an acceptable format for Flickr. The Export tool could even expose the Flickr specific attributes that don't map to Chandler attributes to show up in the detail view of the item...

(iPhoto faces the same problem and deals with Flickr as a separate export tool...The photo albums you manipulate in the iPhoto app aren't linked to Flickr sets or tags. I think we can do something more integrated job than that...but it's a good example to look at. I've included a screenshot.)

But I don't think we want to create separate sub-Kinds and Stamps for each file format...Flickr photos, Shutterfly photos, oFoto photos, Kodak photos, Snapfish photos, etc...

Flickr sets and Chandler collections: What's the connection?

I think we also want all collections in the sidebar to act like any other collection in Chandler...so if you pull down a Flickr set into the sidebar...the Chandler instantiation of it is really loosely coupled with the Flickr set on the website...Maybe a better way to think of it is that you've piped the Flickr set into a Chandler collection*...and the collection in the sidebar is still a full-fledged Chandler collection, which means it's agnostic when it comes to Kinds and file formats. You can add emails, documents, other media kinds, contacts etc... to it.

*Maybe the Flickr pipe is reflected as a rule on the collection that the user can manipulate in the GUI rule builder. Here's an offensive example:

• Project: Gerries contains "All things About: Bob Hope" and pulls down pictures from my "Flickr set called Social Security".
• What feeds an item belongs to might be reflected in the detail view in a special Feeds: attribute that can't be promoted to be a 1st class Chandler collection in the sidebar.

The Chandler collection in the sidebar can still sync with the Flickr set to upload and download images to and from Flickr, but there isn't a strict 1:1 relationship between the Chandler collection in the sidebar and the Flickr set you subscribed to.

Similarly, if you subscribe to a mailing list or an RSS feed, you could either create a new collection for every feed, or you could "feed" the feed into an already existing Chandler collection. So a single Chandler collection: "All my RSS feeds" could have multiple RSS pipes going in and out of it. So I think we shouldn't stop anyone from maintaining pristine: domain specific collections in their sidebar. But if someone doesn't want a separate collection for every feed they ever subscribe to, they can treat the RSS feeds as tubes that can plug into one or more of their sidebar collections. They can always manage the RSS feeds individually through the rule builder.

Workflow proposal:

1. DnD a photo into Chandler
2. Chandler recognizes it's an image from the file format
3. Chandler automatically stamps it as a photo, adding the photo sub-Kind's bag of attributes
4. User goes to File>>Export>>Flickr photo, Flickr set or Flickr tag: Depending on whether the user had a single photo selected or the collection in the sidebar selected, different options are greyed out.
5. Flickr attributes (that can't be mapped to Chandler attributes--if there are any) are added to the Detail view of the item and/or the Detail view of the collection (if the whole collection is being uploaded).
6. Now in the future, hitting the Sync button in the toolbar will sync either the individual photo(s) or the collection with Flickr. (Haven't figured out when the first sync would happen. Maybe the Send button doubles as an Upload button.)

• iPhoto Flickr export dialog
• FlickrExport^?.png: