-
Notifications
You must be signed in to change notification settings - Fork 123
Collections: Ontology + Descriptions
The canonical collections within a locker are represented below, along with current thinking about the ontology or composition paths that define the loose relationships between them, where appropriate.
All field values should be annotated with a 'via' tag to identify path of composition and to support granular permissioning.
Description: The contacts collection composes its objects from the contact/* service types of all connectors in the locker. The fields therein are matched and merged where possible, giving a representation of the people that are known in a person's services.
Basic Contents: General identifiers found on an individual's profile or contact record. Ie, first name, last name, email(s), linked accounts, age, gender, address, recent activity from linked accounts (?), nature of relationship.
Composed Via: Any connector publishing contact/* events.
Related Collections:
Description: The links collection composes its objects from the link/* service types of all connectors in the locker.
Basic Contents: The link, the results of a HEAD request against the link, and the timestamp of that HEAD request. Full links are also stored alongside links provided via shortening services.
Composed Via: Any connector publishing link/* events.
Related Collections:
Description: The photos collection composes its objects from the photo/* service types of all connectors in the locker. Duplicate photos are merged and linked by reference when possible, but merging is done conservatively in this collection. Basic Contents: Image reference URL (currently to external source, soon to media in blob storage), image size (resolution and dimensions), image format, EXIF data, tagged people, source contact, geo tag, timestamp, image name and any comments associated with the image (?).
Composed Via: Any connector publishing photo/* events and the other collections referenced above.
Related Collections:
To Consider: Are 'images' and 'photos' different collections, with different contents?
Description: The events collection composes its objects from the event/* service types of all connectors in the locker. Events minimally reflect a name and time, but can expand to include a multitude of data points.
Basic Contents: Events must have a name and a time, though the name can be set as a composite of the service that created the event and the time of the event if no other name exists. Events can also contain places, contacts (or other people), messages, photos, videos, music and other content.
Composed Via: Any connector publishing event/* events and the other collections referenced above.
Related Collections: (see notes above)
Description: The places collection composes its objects from the place/* service types of all connectors in the locker.
Basic Contents: Places minimally reflect a location defined by at least one of the following: place name, lat/long pair, street address. Places can also contain all of those identifiers, as well as POI tags, neighborhood info, people tags, photos and a number of other data types.
Composed Via: Any connector publishing event/* events and the other collections referenced above.
Related Collections: (see notes above)
To Consider: Places, checkins and paths (tracks) are all different things?
Description: The statuses collection composes its objects from the status/* service types of all connectors in the locker.
Basic Contents: Status updates from various services. (more data is required on the definition of this one)
Composed Via: Any connector publishing status/* events.
Related Collections:
Description: Initially, this collection is meant to represent the metadata related to musical tracks in a user's collection, with an optional content resolution URI. It comprises the objects from the music/* service types for connectors. Whenever possible, track metadata should be matched and merged, but this is, in general, a very hard problem and should not be solved all at once.
Basic Contents: A bundle of "unique" identifiers (MusicBrainz ID, MusicIP PUID, TRM, Rovio / Gracenote URIs), content-resolution URIs (last.fm / Rhapsody / Rdio / Spotify / iTMS), and "fallback" metadata (track name, artist name, release name, release date, label name). Right now it seems like a listening history could be represented as a journal. TODO: decide whether tracks should have a lockerspace-specific ID, or whether to simply use one of the other unique identifiers -- internal apps and connectors shouldn't presume that any user interaction is necessary to create a track that doesn't already exist in a canonical (e.g. Musicbrainz) metadata store.
Composed Via: Any connector publishing music/* events.
Related Collections: Journals, Photos