After I pulled music out into a separate spec, I recieved feedback that
this makes the two specs together harder to use. Also, from an editorial
perspective, it made it more complicated to maintain the
cross-references between the extension specs and the schema spec.
With that in mind, I've pulled music back into the main spec, but it is
now in a section of its own distinct from the base schema. I also took
this opportunity to move a few more things out into their own sections,
though this work is not yet complete.
With what we have in the spec today, I think we need the following
additional non-core sections:
* Products and services - to include the existing TV Episode, Movie
and new types such as Musician (or band), Venue (possibly with
specializations such as "restaurant" TBD), and also the new type
"review" as a special kind of comment. It is likely that music album
will also become a specialization of product.
* Blogging - to include weblog-entry and a new type "weblog" to model
folks posting a pointer to their blog as a whole rather than to a
specific entry. (Which is something now present in the wild on TypePad)
* Photos - include photos and photo albums.
...and likely more. I just wanted to post this to let people know about
this new direction. I'd love to talk about this some more at IIW next
Tuesday.
Indeed.
> For example, "venue" seems something that should come from vcard or vcal
> entries... I don't see why we'd include a new attribute for venue, unless
> were specifying how to extract location information from somewhere in a
> feed...?
However we express the location and name of a venue, we need to have it
as an object type so that it can be referred to as the actor, object or
target of an activity. In practice it might just be called "place" if
there's no use-case for specializing places where events typically
occur, but that remains to be seen.
Example use-cases for a venue or place object type are:
* Venue-specific notes and reviews on sites such as Last.fm, Eventful, etc.
* Checkins and other location-sensitive things on
BrightKite/FourSquare/etc. (We may find that we can represent this in
some other way, of course, such as an activity of posting a note with
location context.)
* On sites where venues are a social object -- of which there are many
including BrightKite/FourSquare/Last.fm/Eventful/Eventbright/Upcoming...
-- there's the usual social object interactions such as adding a new
one, editing an existing one, sharing one with a friend, etc, etc.
"Other formats" don't help us because we're in Atom, so whatever we
represent we need to figure out what it looks like in Atom. Sometimes
there's already a spec for representing something in Atom. Other times
there's some existing practice we can write into a spec. Sometimes there
are other formats that can be used as a basis for an Atom
representation, and in a few rare cases there is no existing precedent
and we need to make something up.
> However, also learning from other specs, having a document that reads well
> without referring or deferring to dozens of other specs can improve adoption
> and comprehension, so we must always keep an eyes towards making it easy for
> implementors (consumers and publishers) to adopt the format.
>
My goal now is to shrink the "core" or "base" schema as much as possible
and ultimately bake it so that others can start to implement without
fear that it'll change drastically as it has done a few times so far.
Then we can work on expanding out the more specialized sections.
However we express the location and name of a venue, we need to have it
> For example, "venue" seems something that should come from vcard or vcal
> entries... I don't see why we'd include a new attribute for venue, unless
> were specifying how to extract location information from somewhere in a
> feed...?
as an object type so that it can be referred to as the actor, object or
target of an activity. In practice it might just be called "place" if
there's no use-case for specializing places where events typically
occur, but that remains to be seen.
"Other formats" don't help us because we're in Atom, so whatever we
represent we need to figure out what it looks like in Atom. Sometimes
there's already a spec for representing something in Atom. Other times
there's some existing practice we can write into a spec. Sometimes there
are other formats that can be used as a basis for an Atom
representation, and in a few rare cases there is no existing precedent
and we need to make something up.
GeoRSS is one option for giving the location of a venue or place.
However, what we need for Activity Streams is always a way to represent
an object as an Atom entry. GeoRSS provides properties we can use to
encode the location of the place, but it doesn't provide us with a
mechanism to say "this entry represents a place". That's what
activity:object-type is for, of course.
>
> I understand your use cases and agree that location/venue will be essential
> to activity streams. One need only take a look at Yelp's iPhone app to see
> evidence of this:
>
> http://www.flickr.com/photos/factoryjoe/3540756683/
>
> That said, I think that we actually need to think about location in a
> general sense — for the benefit of any ATOM feed — where an activity stream
> or not. That's why I'd defer to something like vcard or GeoRSS first and
> then fill in the gaps that's missing — even if it's just making those
> formats/schemas work for ATOM.
>
The only gap I'm proposing to fill in here is making an object-type for
"place". I certainly don't plan to invent yet another way to specify the
location of that place when there are suitable mechanisms already.
The guys at BuddyCloud [1] are doing some interesting stuff in regards
to assigning a meaning to a location, e.g. defining a place. I thought
this might interest some of you. They're using XMPP but the ideas they
explore is really worth the look.
- Sylvain