Proposal: Create a 'photos' collection for cross-app data sharing

Apps
#1

We’ve discussed building formal support for collections for quite some time. It’s about time to make that a priority, and this is something we could make a reality in Q1 2019.

I’d love to chat here about a possible data schema for a ‘photos’ collection.

We have multiple photo-related apps being built:

Migrating these apps to use some form of a shared photos collection would do a lot to deliver on the promise of decentralization.

What I’d like to do here is get some proposals for a data schema for a photos schema.

Some fields that I can think of:

  • photo URL (the raw photo, stored in Gaia)
    • this should probably be a reference to multiple ‘blobs’, to support large photo files
  • date added
  • name
  • description
  • tags
  • EXIF metadata

Let’s try and clean this up into a more formal schema, maybe using JSON schema.

3 Likes
Collections Super thread
Accessing same gaia data from multiple domains
#2

My “Does it matter” questions are me trying to understand what is important in setting up these schemas, not related to the proposed property’s importance.

Field by field comments and questions below:

  • photo url - agree it should be an array of URLs.
  • date added - is there a way to specify format? Unix timestamp would be ideal. Does format matter? Does “date added” mean photo creation date? Or date it was uploaded? Do we need to differentiate that level of detail in a schema? Create date should be in the exif data, assuming its preserved.
  • name - file name? Or a user/app generated name? Does it matter?
  • description - String of what length? Does it matter?
  • tags - ok, comma sepated strings? An array of strings?
  • Exif metadata - I believe this should only be available within the photo. No need to replicate in a separate structure.
  • annotation - I propose an additional free form field that could be used to identify photographer or whatever information my be important to any specific apps users.
1 Like
#3

Mumble and Sigle (@leopradel) might benefit as well (read-only permission)

1 Like
#4

In Android (https://developer.android.com/reference/android/provider/MediaStore.Images.ImageColumns.html) you find in addition:

  • date taken
  • date expires
  • date modified
  • duration (for gifs or videos)
  • height, width (in pixels)
  • mime-type
  • orientation (in degree, like 0, 90, 180, 270)
  • size
  • title (android has two properties: display-name (=file name) and title)
#5

Most of these can be derived if exif information exists, or, in the case of size, directly from the photo. Also, props should be informed by this:

https://schema.org/Photograph

So we maintain some general consistency, imo.

1 Like
#6

One use case for the photo collection is that the user can choose from his photos easily within an app. The app shouldn’t need to parse and analyze all the photo files (only one image file is needed in the end), instead the app should be able to get a concise list of meta data that can be displayed in a chooser dialog or so. Maybe the collection should even contain a thumbnail.

Another use case for the photo collection is to view a slide show with the photos. Then the app would get the concise list but only use the photo urls. Other data could be extracted from the photo itself because the app needs the full image file anyway.

#7

Collections should be a minimal footprint that enables data portability. Duplicating fields potentially leads to conflicting data. ie. how does my new photo app handle the situation where exif data has one create date and ‘date taken’ is completely different? As a user I expect this to be handled in a consistent manner and when we duplicate fields, I think we throw open the possibility that apps will behave very differently.

Any fields that are already part of existing document metadata can be duplicated within an app, but should not be part of a shareable schema, imho.

#8

@dant Fully agree. I didn’t mean to duplicate fields.

However, the specific exif tag DateTime has an issue because it defines the modify date and does not specify a time zone.

I suggest to remove exif as a field in the collection schema, as it has too many information with its 30 tags that is not used for an image picker or gallery. We could add a url to an exif file.