Pulling Music back into the main schema spec; separating base from app-specific schemata

[Martin Atkins]

Hi all,

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.

[Chris Messina]

Looking forward to talking about this and other things at IIW.

I am a bit worried about the balance we must strike between being a well-scoped spec and one that is bloated with special cases and data that should be captured in other formats.

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, 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.

Chris

--
Chris Messina
Open Web Advocate

factoryjoe.com // diso-project.org // openid.net
This email is:   [ ] bloggable    [X] ask first   [ ] private

[Martin Atkins]

Chris Messina wrote:
> Looking forward to talking about this and other things at IIW.
> I am a bit worried about the balance we must strike between being a
> well-scoped spec and one that is bloated with special cases and data that
> should be captured in other formats.
>

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.

[Chris Messina]

On Sun, May 17, 2009 at 8:45 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:

> 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.

"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.

What about GeoRSS? Or is that like MediaRSS and we need something more like GeoATOM?

Or, are we talking about something less mathematical and more human-friendly?

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.

Chris

[Martin Atkins]

Chris Messina wrote:
>
> What about GeoRSS? Or is that like MediaRSS and we need something more like
> GeoATOM?

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.

[Sylvain Hellegouarch]

2009/5/18 Martin Atkins <ma...@degeneration.co.uk>:

>
> Chris Messina wrote:
>>
>> What about GeoRSS? Or is that like MediaRSS and we need something more like
>> GeoATOM?
>
>
> 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.
>

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

[1] http://www.buddycloud.com/cms/node/92

[Scott Seely]

If we are going to merge this with OpenSocial, I'd like to see us use the OpenSocial address element, which is based on the vCard address element and incorporates latitude/longitude positioning for places that aren't on a street (think national parks, middle of a lake, etc.).

 

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#addressElement

 

---

From: activity...@googlegroups.com on behalf of Martin Atkins
Sent: Mon 5/18/2009 10:14 AM
To: activity...@googlegroups.com
Subject: Re: Pulling Music back into the main schema spec; separating base from app-specific schemata

[Scott Seely]

In OpenSocial, we found that Music, Pictures, and Movies are all pretty similar and named them MediaItems with a special MediaType to differentiate they type of media. In this case, Albums can then contain mixtures of these types. I'd be curious to know where MediaItem does and doesn't fit with the current Activity notions.

 

See http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.3.6.

---

From: activity...@googlegroups.com on behalf of Martin Atkins

Sent: Sat 5/16/2009 12:42 PM
To: Activity Streams
Subject: Pulling Music back into the main schema spec; separating base from app-specific schemata

[Chris Messina]

Generally that sounds pretty good.

I think that the media distinction based on MIME type could be a bit of a rathole. Someone at IIW mentioned that we're starting to see music and movies interspersed in collections, so keeping them distinct really doesn't make much sense (just look at how iPhoto and Flickr both support video now!). 

So, I think having a generic "container" or better "collection" concept is a good idea... and then using subtypes of "mediaItem" to refer to media objects would be a good way to align with OpenSocial.

How does this work with AtomMedia?

Chris

--
Chris Messina
Open Web Advocate

Website: http://factoryjoe.com
Twitter: http://twitter.com/chrismessina
Facebook: http://facebook.com/chrismessina

Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

[Elias Bizannes]

Thought I might chip in here on how we are defining things. For some context - at the DataPortability Project, we are working on creating a EULA/ToS system that can be standardised across the Internet, as an add-on module for existing EULA's, to allow consumers to specify licensing of their data. (We're using the Creative Commons as inspiration.)

But to do that - we had to work out what data was. We've identified three categories:

- Identity

- Media

- Metadata (or "structures")

We're defining them as follows: Identity is data that makes a representation of a human, media is an expression by a human, and meta data is data about other data. So an email address and someones gender is "identity data"; a Flickr photo or Youtube video is "media data" whereas a playlist of songs, EXIF data of a photo, and relationships between friends is considered "meta data".

Trying to drill down any further, at least for us, doesn't yield any marginal benefit. I would argue drilling too much into types here could also be problematic. Sure, you do make it more accurate, but as mentioned earlier, sometimes it can get confusing on what to classify something. These three broad categories are distinct enough to not be confused with one another, but specific enough to give data objects within them unique treatment that's relevant.

Elias Bizannes
http://eliasbizannes.com

[David Recordon]

I like this given that it is logical (see emails from Chris and Elias), maps into what applications focused on these media types are evolving into and would be based on what another standard is doing.

--David

[Monica Keller]

It does sound clear and simple but we would need to get a working
example of how we can actually build products using this limited set.
We were planning on having the language, verb and object type map to a
given template for display of the activity

On May 26, 10:14 am, David Recordon <da...@sixapart.com> wrote:
> I like this given that it is logical (see emails from Chris and  
> Elias), maps into what applications focused on these media types are  
> evolving into and would be based on what another standard is doing.
>
> --David
>
> On May 19, 2009, at 1:53 PM, Scott Seely wrote:
>
>
>
> > In OpenSocial, we found that Music, Pictures, and Movies are all  
> > pretty similar and named them MediaItems with a special MediaType to  
> > differentiate they type of media. In this case, Albums can then  
> > contain mixtures of these types. I'd be curious to know where  
> > MediaItem does and doesn't fit with the current Activity notions.
>

> > Seehttp://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RES...
> > .

> > Tuesday.- Hide quoted text -
>
> - Show quoted text -