Another modest proposal: Actors and authors for Atom format

[John Panzer]

All,

I volunteered to look into the author/actor issue and come up with a proposal.  Here's my take, based on prior list discussion plus wrestling with Activity Streams + Salmon:

* By default, if there is no <activity:actor>, the <atom:author> is also the actor (contains the actor information).

* It's fine to put additional atom-namespace elements inside author, per discussion on the Atom list.  We should submit a patch to the feed validator that fixes its warning about this, probably along with a patch that fixes its scary warning about an unknown activity: namespace.

* We should support activity:object-type inside atom:author but it should default to .../person if omitted.

* We should support atom:id inside atom:author but it defaults to author/uri if omitted.

* We should use the existing <atom:name> instead of <atom:title>, as <atom:name> is already supported 

* We should support poco: fragments for details of names, etc.

* I think that, for the Atom serialization, inheriting Actor from the Person construct is the right thing to do.  There's no reason why Actor can't have all the fields desired, but it's a lot easier for the serialization if you don't have to do odd mappings like title -> name.

Example (pretty fully spelled out):

<author>

  <uri>http://blah/geraldine</uri>

  <activity:object-type>http://activitystrea.ms/schema/1.0/person</activity:object-type>

  <id>tag:photopanic.example.com,2009:/Person/4859568</id>

  <name>Geraldine</name>

  <link rel="alternate" type="text/html" href="http://blah/geraldine" />

  <poco:name>

     <poco:givenName>Geraldine</poco:givenName>

     <poco:familyName>Blevins</poco:familyName>

  <poco:name>

</author>

Shortened example, taking advantage of intelligent defaults while not losing information:

<author>

  <uri>http://blah/geraldine</uri>

  <name>Geraldine</name>

  <poco:name>

     <poco:givenName>Geraldine</poco:givenName>

     <poco:familyName>Blevins</poco:familyName>

  <poco:name>

</author>

A feature of this serialization is that you don't have to repeat anything in a separate activity:actor element, you can extend author as needed (with things like atom:link and poco:name), but you still have full compatibility with existing Atom feeds -- they'll ignore the poco stuff and use uri and name for reasonable purposes.

Note that if there's ever a use case where author != actor you would still separate the two.  I don't think we have one of these use cases today, but the semantics would be : "This author says that actor X did action Y on object Z".  This is important for things like Salmon because the entity doing the signing is still the author, who may or may not be trusted to say things about what X did.

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Monica Keller]

On Tue, Mar 2, 2010 at 4:50 PM, John Panzer <jpa...@google.com> wrote:

All,

I volunteered to look into the author/actor issue and come up with a proposal.  Here's my take, based on prior list discussion plus wrestling with Activity Streams + Salmon:

* By default, if there is no <activity:actor>, the <atom:author> is also the actor (contains the actor information).

* It's fine to put additional atom-namespace elements inside author, per d

iscussion on the Atom list.  We should submit a patch to the feed validator that fixes its warning about this, probably along with a patch that fixes its scary warning about an unknown activity: namespace.

Excellent

* We should support activity:object-type inside atom:author but it should default to .../person if omitted.

* We should support atom:id inside atom:author but it defaults to author/uri if omitted.

Interesting this seems like something that could be extended to all objects

* We should use the existing <atom:name> instead of <atom:title>, as <atom:name> is already supported 

Once again the question is if we make this more generic. Seems like it fits well for groups, photos, videos... less so for blog entries or articles

* We should support poco: fragments for details of names, etc.

Yea !

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

[Bill de hOra]

John Panzer wrote:
> All,
>
> I volunteered to look into the author/actor issue and come up with a
> proposal. Here's my take, based on prior list discussion plus wrestling
> with Activity Streams + Salmon:

Hi John,

thanks for taking this on.

> * By default, if there is no <activity:actor>, the <atom:author> is also
> the actor (contains the actor information).

+1.

> * It's fine to put additional atom-namespace elements inside author, per
> discussion on the Atom list. We should submit a patch to the feed
> validator that fixes its warning about this, probably along with a patch
> that fixes its scary warning about an unknown activity: namespace.

+1.

> * We should support activity:object-type inside atom:author but it
> should default to .../person if omitted.

-1. Pick one option.

> * We should support atom:id inside atom:author but it defaults to
> author/uri if omitted.

-1. Pick one option.

> * We should use the existing <atom:name> instead of <atom:title>, as
> <atom:name> is already supported

+1

> * We should support poco: fragments for details of names, etc.

-1 until PoCo is revived and its dependencies are sorted out.

> * I think that, for the Atom serialization, inheriting Actor from the
> Person construct is the right thing to do.

+1

Bill

[Chris Messina]

On Wed, Mar 3, 2010 at 3:02 PM, Bill de hOra <bi...@dehora.net> wrote:

John Panzer wrote:

I volunteered to look into the author/actor issue and come up with a proposal.  Here's my take, based on prior list discussion plus wrestling with Activity Streams + Salmon:

* By default, if there is no <activity:actor>, the <atom:author> is also the actor (contains the actor information).

+1.

+1.

 

* It's fine to put additional atom-namespace elements inside author, per discussion on the Atom list.  We should submit a patch to the feed validator that fixes its warning about this, probably along with a patch that fixes its scary warning about an unknown activity: namespace.

+1.

+1.

 

* We should support activity:object-type inside atom:author but it should default to .../person if omitted.

-1. Pick one option.

I'm +1 to John's proposal. 

Picking one makes things simpler, but I like the idea of being able to have non-person "actors" in ActivityStreams, as indicated by the author object-type. For example, a service could be an author, or some kind of bot or program. There will be cases where no object-type is indicated, and in those cases, we should default to a .../person object.

 

* We should support atom:id inside atom:author but it defaults to author/uri if omitted.

-1. Pick one option.

I'm ambivalent. Seems like author/uri is sufficient here.

John: can you make a case?

 

* We should use the existing <atom:name> instead of <atom:title>, as <atom:name> is already supported

+1

+1.

 

* We should support poco: fragments for details of names, etc.

-1 until PoCo is revived and its dependencies are sorted out.

+1 to using PoCo. Bill: what do you mean "revived"? What dependences are you referring to?

Just because it hasn't been modified recently doesn't mean that it isn't solid as is... what is it missing?

 

* I think that, for the Atom serialization, inheriting Actor from the Person construct is the right thing to do.  

+1

+1.

Chris

 

Bill

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[Martin Atkins]

Per the last meetup at the 6A office, in the new draft I'm saying that
the author as defined by the Atom specification is the actor, and that
it is parsed the same way as an object represented as an entry except that:

* atom:name is used instead of atom:title.
* atom:uri is supported as well as link rel="alternate" type="text/html".

The section on "object represented as atom:author" is not yet in the new
refactored spec draft, but I hope to finish up the first complete draft
of the new, refactored spec this week.

The above is what I implemented in the activity streams tester app.

The only deviation from the original proposal by John in the tester app
(which is implemented based on what the new spec says in my head...) is
that it currently treats an atom:author element without an explicit
object-type as a typeless object rather than a person. If we refine the
definition of "person" to match how Atom defines it in the definition of
its Person construct then I see no reason why we wouldn't default it as
John proposed.