Extending Actor

[Monica Keller]

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-01 ?

or

http://portablecontacts.net/draft-schema.html --> This is what Cliqset
is using


Main things we need for the actor
- Profile picture
- Full Name
- External Identity --> Url on Twitter or Facebook

Looks like Poco has a good representation for external accounts

We also need a way to communicate additional properties on the actor
like # of friends and account type.

What other properties do you need on the actor ?

[Martin Atkins]

It has been on my todo list for some time to write an ancillary spec on
how to use PortableContacts elements within an Atom entry, but I have
not yet got to it.

The main things that this spec needs to cover are:
* that in the Atom context it is required to use the PoCo XML namespace
for the PoCo elements.
* that certain PoCo elements are not permitted because there's already
an existing Atom element that can be used to communicate the same
information in a way that will be visible to generic feed readers: for
example, I intended that displayName would be disallowed and this spec
would encourage the use of "title" instead.

The activity schema spec would then refer to this orthogonal spec, much
as it currently refers (more or less) to AtomMedia.

If someone else would be interested in taking on a "people in Atom based
on PortableContacts" specification then please let me know! :)

[Kevin Marks]

Isn't the existing OpenSocial Person Atom representation what we need here?

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

+jpanzer, who helped write this mapping originally

--

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.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

[Martin Atkins]

Kevin Marks wrote:
> Isn't the existing OpenSocial Person Atom representation what we need here?
>
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.3.2
>
> +jpanzer, who helped write this mapping originally
>

AFAICT OpenSocial's standard Atom mapping mechanism is to nest the
OpenSocial XML inside atom:content. While that's a valid approach,
that's not how these things have generally been handled elsewhere in
Activity Streams where we allow atom:content to be an HTML
representation of the entry for fallback purposes.

However, the process of pulling certain Portable Contacts (and
OpenSocial) fields out into equivalent atom:-namespaced elements is
exactly what I had in mind with my second bullet point.

As usual, I find myself wishing that OpenSocial was built from small
parts loosely joined rather than one huge specification covering a wide
range of use-cases, since it makes it hard to borrow from it.

[Bill de hOra]

Martin Atkins wrote:
> Kevin Marks wrote:
>> Isn't the existing OpenSocial Person Atom representation what we need here?
>>
>> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.3.2
>>
>> +jpanzer, who helped write this mapping originally
>>
>
> AFAICT OpenSocial's standard Atom mapping mechanism is to nest the
> OpenSocial XML inside atom:content. While that's a valid approach,
> that's not how these things have generally been handled elsewhere in
> Activity Streams where we allow atom:content to be an HTML
> representation of the entry for fallback purposes.

My guess is that was done to maintain some kind of lexical mapping with
the original javascript format (it's definitely different from what I'll
call the "gdata" approach which AS follows and I tend to prefer myself*.

> As usual, I find myself wishing that OpenSocial was built from small
> parts loosely joined rather than one huge specification covering a wide
> range of use-cases, since it makes it hard to borrow from it.

+1. I wonder if this isn't reasonable

<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:os="http://ns.opensocial.org/2008/opensocial">
<os:person>
<os:name>
<os:unstructured>Jane Doe</os:unstructured>
</os:name>
<os:gender>female</os:gender>
</os:person>
<title/>
<updated>2003-12-13T18:30:02Z</updated>
<author/>
<id>urn:guid:example.org:34KJDCSKJN2HHF0DW20394</id>
</entry>

or dump the nesting altogether and get rid of a *lot* of anglebracket noise:

<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:os="http://ns.opensocial.org/2008/opensocial">
<os:unstructured>Jane Doe</os:unstructured>
<os:gender>female</os:gender>
<title/>
<updated>2003-12-13T18:30:02Z</updated>
<author/>
<id>urn:guid:example.org:34KJDCSKJN2HHF0DW20394</id>
</entry>

given that OS is defined as essentially key value pairs anyway in the
abstract.

Bill


* This kind of lexical craziness in APIs must be wasting millions of
dollars every year. It's why I still think RDF's syntax independent
graph has a future - you just take the bits of vocabulary you need as
you need them.

[John Panzer]

Yes, the OpenSocial stuff was defined independent of Atom (or anything else, really) initially, which led to quite a few issues.

I still think (per discussion today at IIW) that it'd be useful to talk about using the Atom Person construct (used for atom:author, atom:contributor) and extending it as needed with PoCo elements, rather than representing people as atom:entries.  No existing aggregator is going to do anything useful with a person represented as an atom:entry inside another atom:entry (which I think is the use case here).  They will do something possibly halfway intelligent with atom:author (name, possibly uri).  And they will ignore anything else under atom:author or atom:contributor.

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

[Rob Dolin]

FWIW, I like John's suggestion here of nesting the data within the appropriate person element.

 

I'm imagining you could do something like:

<author>

  <title>John Smith</title>

  <??:gender>male</??:gender>

</author>

 

or

 

(Example from MySpace's <activity:actor> in their Activity Streams feed with the gender element added)

<activity:actor>

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

  <id>tag:myspace.com,2009:/Person/473185983</id>

  <title>Tess Ting</title>

  <link rel="alternate" type="text/html" href="http://www.myspace.com/tesstingms"/>

  <link rel="avatar" type="image/jpeg" href="http://c2.ac-images.myspacecdn.com/images02/75/s_94cbd2c0ed5e4ef0a4bc02a10aecc011.jpg"/>

  <??:gender>male</??:gender>

</activity:actor>

--

[John Panzer]

Sorry, I was joining two discussion streams, one in Real Life at IIW and one on this discussion list.  At IIW, we were asking why AS isn't apparently using atom:author to represent the initiator of actions like posting, commenting, rating, liking, favoriting, etc.  (And extending it with PoCo of course.)  Instead apparently you add an atom:entry inside an actor element which is inside an activity atom:entry -- please forgive me if I got this wrong, I haven't been able to go through the spec again yet, this is what I got from the discussion.

This is a different case from when you have something like a collection of People that you're doing things with, which is the OpenSocial "person" API's use case (and PoCo's original use case, and Google Contacts, and...).

I just hope that the same fields & extensions can be used no matter what the wrapper is, and especially in the case of data carried along with an activity, comment, etc.:

1. Nickname (just a string, non-unique, human readable, UTF-8: "Bob") - I think this is just called "name" in Atom
2. Unique URI that can be used to identify the person and ideally can be discovered to get more data if desired - atom:uri or link rel
3. Photo/avatar or service pointer to trivially get same - link rel, hopefully

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

[John Panzer]

Yup, though with standard Atom you just say "name" (http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.3.2).  I just noticed you can have multiple atom:author elements too, so that takes care of Chris Messina's use case of having two actors jointly publishing their newly found friendship.

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

[Darren Bounds]

Here's how we're extending Actor to get some additional granularity via PoCo:

<activity:actor xmlns:poco="http://portablecontacts.net/spec/1.0">

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

<id>dbounds</id>
<poco:name>
<poco:givenName>Darren</poco:givenName>
<poco:familyName>Bounds</poco:familyName>
</poco:name>
<link xmlns:media="http://purl.org/syndication/atommedia"
type="image/png" rel="avatar"
href="http://dynamic.cliqset.com/avatar/dbounds?s=80"
media:height="80" media:width="80"></link>
<link xmlns:media="http://purl.org/syndication/atommedia"
type="image/png" rel="avatar"
href="http://dynamic.cliqset.com/avatar/dbounds?s=120"
media:height="120" media:width="120"></link>
<link xmlns:media="http://purl.org/syndication/atommedia"
type="image/png" rel="avatar"
href="http://dynamic.cliqset.com/avatar/dbounds?s=200"
media:height="200" media:width="200"></link>
</activity:actor>

--
darren bounds
dar...@cliqset.com

[Monica Keller]

We are going to do it identically except for dbounds would go in
<atom:title> instead of <atom:id>
For id we use truly unique ids with the tags

We are also going to look at syndicating other user accounts that we
know are associated like the twitter account

> > href="http://c2.ac-images.myspacecdn.com/images02/75/s_94cbd2c0ed5e4ef0a4bc..."/>

>
> >   <??:gender>male</??:gender>
>
> > </activity:actor>
>

> > From: John Panzer [mailto:jpan...@google.com]
> > Sent: Wednesday, November 04, 2009 7:28 PM
> > To: Bill de hOra
> > Cc: activity...@googlegroups.com
> > Subject: Re: Extending Actor
>
> > Yes, the OpenSocial stuff was defined independent of Atom (or anything else,
> > really) initially, which led to quite a few issues.
>
> > I still think (per discussion today at IIW) that it'd be useful to talk
> > about using the Atom Person construct (used for atom:author,
> > atom:contributor) and extending it as needed with PoCo elements, rather than
> > representing people as atom:entries.  No existing aggregator is going to do
> > anything useful with a person represented as an atom:entry inside another
> > atom:entry (which I think is the use case here).  They will do something
> > possibly halfway intelligent with atom:author (name, possibly uri).  And
> > they will ignore anything else under atom:author or atom:contributor.
>
> > --
> > John Panzer / Google

> > jpan...@google.com / abstractioneer.org / @jpanzer

>
> > On Wed, Nov 4, 2009 at 6:54 PM, Bill de hOra <b...@dehora.net> wrote:
>
> > Martin Atkins wrote:
>
> > Kevin Marks wrote:
>
> > Isn't the existing OpenSocial Person Atom representation what we need here?
>

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

> dar...@cliqset.com- Hide quoted text -
>
> - Show quoted text -

[Rob Dolin]

FWIW, if Darren has both a username on the service and has shared his full name, it would be good for the stream to include both of these (i.e. "dbounds" and "Darren Bounds").

[Martin Atkins]

John Panzer wrote:
> Yes, the OpenSocial stuff was defined independent of Atom (or anything
> else, really) initially, which led to quite a few issues.
>
> I still think (per discussion today at IIW) that it'd be useful to talk
> about using the Atom Person construct (used for atom:author,
> atom:contributor) and extending it as needed with PoCo elements, rather
> than representing people as atom:entries. No existing aggregator is
> going to do anything useful with a person represented as an atom:entry
> inside another atom:entry (which I think is the use case here). They
> will do something possibly halfway intelligent with atom:author (name,
> possibly uri). And they will ignore anything else under atom:author or
> atom:contributor.
>

While I could potentially be convinced, I'm reluctant to have two
different ways to represent people in activity streams.

The needless differences between Person constructs and Entry constructs
(title becomes name, most of the elements are missing, uri instead of
link rel="alternate") are frustrating when it comes to re-using an
implementation of parsing an XML element representing a person in the
"object" property versus the "actor" property.

As currently written (for better or worse) Activity Streams is more
riding on top of Atom than extending it. Much like publishers use
atom:content to provide a fallback for non-activity processors, most
publishers today provide a minimal atom:author element alongside
activity:actor as a fallback, and while this is a little more verbose it
achieves the desired goal of giving pure Atom processors something to
chew on, and activity:actor is consistent with activity:object and
activity:target in being completely invisible to non-Actity processors.

[1] http://github.com/apparentlymart/activity-streams-python

[Bill de hOra]

> I still think (per discussion today at IIW)
> that it'd be useful to talk
> about using the Atom Person construct
> (used for atom:author,
> atom:contributor) and extending it as
> needed with PoCo elements

So maybe this is a way forward? -

<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:os="http://ns.opensocial.org/2008/opensocial">

<author>
<name>John Doe</name>
<uri>http://example.org/</uri>
<email>f8...@example.com</email>

<os:gender>female</os:gender>

<os:id>example.org:34KJDCSKJN2HHF0DW20394</os:id>
<os:displayName>Janey</os:displayName>
...
</author>

<title/>
<updated>2003-12-13T18:30:02Z</updated>
<author/>
<id>urn:guid:example.org:34KJDCSKJN2HHF0DW20394</id>
</entry>

with defined mappings, where

atom:author -> os:person
atom:name -> os:name
atom:email <-> os:email
atom:uri <-> os:url

"->" for atom fields that are non-optional, "<->" for where you could
use atom:* author or os:* constructs, possibly preferring atom:* because
the data will show up in bog-standard readers. Coding to this should be
straightforward.

Bill

John Panzer wrote:
> Yes, the OpenSocial stuff was defined independent of Atom (or anything
> else, really) initially, which led to quite a few issues.
>
> I still think (per discussion today at IIW) that it'd be useful to talk
> about using the Atom Person construct (used for atom:author,
> atom:contributor) and extending it as needed with PoCo elements, rather
> than representing people as atom:entries. No existing aggregator is
> going to do anything useful with a person represented as an atom:entry
> inside another atom:entry (which I think is the use case here). They
> will do something possibly halfway intelligent with atom:author (name,
> possibly uri). And they will ignore anything else under atom:author or
> atom:contributor.
>
> --
> John Panzer / Google

> jpa...@google.com <mailto:jpa...@google.com> / abstractioneer.org
> <http://abstractioneer.org> / @jpanzer

[John Panzer]

These look a lot like the "hoisting rules" proposed for OpenSocial <-> Atom.  I'm still +1 on them (given a goal of being compatible with existing infrastructure).

I will note that from a pure coming-to-this-as-a-new-user perspective, having an element named "title" that isn't a person's title but is actually their name is a bit confusing.  And not having an entry's author inside the <author> element is confusing for people and software that knows about Atom.

--
John Panzer / Google

jpa...@google.com / abstractioneer.org / @jpanzer

[Martin Atkins]

John Panzer wrote:
>
> I will note that from a pure coming-to-this-as-a-new-user perspective,
> having an element named "title" that isn't a person's title but is actually
> their name is a bit confusing. And not having an entry's author inside the
> <author> element is confusing for people and software that knows about Atom.
>

It is unfortunate that we're forced to work within the vocabulary
already established for Atom, but in Activity Streams the atom:title
element is generalized to mean "the name of this thing"; the
specification is very deliberate in always using title in this way such
that it can be used as a fallback (along with the permalink URL) in the
event that there is no special handling for a particular object type in
a particular consumer.

[John Panzer]

I'm probably missing something -- in what case would a person's atom:title ever be processed by a non-Activity-Streams-aware library?  

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

[Martin Atkins]

John Panzer wrote:
> I'm probably missing something -- in what case would a person's
> atom:title ever be processed by a non-Activity-Streams-aware library?

There are a few different fallback cases catered for by Activity Streams:

* Consumer doesn't recognize any of the verbs. In this case, it may
choose to process the activity entry as if it had no activity streams
support at all, or it might drop the activity on the floor completely at
its option.

* Consumer recognizes a verb, but doesn't recognize an object type. In
this case, it can render a generic version of the sentence that uses the
object's title as a proper noun without any reference to its type. For
example:
Martin posted <a href="{permalink}">{title}</a>.

* Consumer doesn't support activity streams at all, in which case it
renders the human-readable description of the activity provided in
atom:title and atom:content within the activity entry, or if the implied
activity shorthand is being used, the atom:title and atom:content of the
object itself.

So there are two cases where the atom:title comes into play here. The
first is when object type is not recognized, and the second is when the
implied activity shorthand is being used by th publisher and the
consumer does not support activity streams.

The implied activity shorthand exists in recognition of the fact that
many feeds today are really lists of objects rather than lists of
activities, and so given the design principle that you shouldn't need to
break how non-activity feed readers process your feed in order to add
activity extensions we provide a way to describe an activity using only
an atom:entry element and no nested atom:object.

[Peter H. Reiser]

I not sure if this is the right email thread .. but I would like to describe a a use case where we struggling at the moment.

 non chronological AS feeds 

UC1: (this one works :.-) )

1. entry:1 an object author:John  publishes an object (e.g. object:blog, author:John, verb:post)

2. entry:2 an actor:Mary views the blog post (object:blog, actor:Mary, verb:play)

Result:

- the object:blog is created with the author:John

- the verb:post counts for actor:John

- the verb:play counts  for actor:Mary (and for John as Mary viewed his blog)

UC2: (does not work :-8 )

1. entry 1: an actor (Mary) views the object:blog (object:blog, actor:Mary, verb:play) 

but the object:blog happened earlier and is not in the feed

Result:

- since the object:blog does no exist  - it creates the object with the author:Mary (because there is no reference to author:John)

-  the verb:play counts  for actor:Mary

- the object:blog is created and the author is assumed to be the actor of the first verb (activity) related to the object  e.g. author:Mary 

Issue: the object author=John  is not known in the  entry hence author:Mary

Questions :

1. Does the AS standard demand to always have the object author in an AS entry ?

2. Could we generally say that the author relates to the object and the actor relates to an activity ?

 (probably not as this would not be read by a standard ATOM reader)

3. How to distinguish between object:author and activity:actor ?

Regards

Peter

[John Panzer]

All of this makes total sense and I agree with it.  My question may have been ambiguous: When would the atom:title for _a person_ (not an activity) be used by non-Activity-Streams-aware code?

In other words, an Activity Stream looks like this:

<feed>

...

  <entry id='a'>

    <title>Monica threw a sheep at Dave</title>

    ... some more structured data, including, somewhere:

       <entry id='b'><title>Monica</title><pc:firstname>Monica</pc:firstname>...</entry>  

  </entry>

</feed>

 

So, the entry with id='a' represents an activity, and will be seen and processed by standard libraries/intermediaries/etc.   So they see the unstructured "Monica threw a sheep at Dave" and ignore everything else, which is the best you can hope for.

The entry with id='b', representing the actor (person) for the activity, is nested inside that first entry, possibly inside some other structure, and is effectively invisible to anything that doesn't know about Activity Streams.  That is, at best it gets passed through ignored and at worst it's stripped out.  So it doesn't really matter _that_ much if it uses "title" or "name" or "fn".

And, if I've just gotten this wrong, my apologies -- this is based on my partial understanding from looking at some subset of the specs and talking to people at IIW.

--

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.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

--

[Martin Atkins]

You are correct that in your example a non-activity-streams-aware
processor will never see tyhe string "Monica" inside the nested entry.
(Which, by the way, would actually have the element name activity:actor
per the current spec.)

However, people can be the object of some activities. For example, the
verb that describes becoming friends with someone has a person as both
its actor and its object.

The Atom serialization includes an "implied activity shorthand" which
can be used when you want your feed to be a list of objects rather than
a list of activities. This is expected to be used most commonly in feeds
for blogs, where today the fact that an entry was posted is implied by
its existence in the feed, so the explicit activity entry is not required.

If we apply the implied activity shorthand to the concept adding
friends, what we end up with is actually a list of person objects with
no containing activity, like this:

<feed>
<title>Martin's Friends</title>
...

<entry>
<title>John</title>
<a:object-type>
http://activitystrea.ms/schema/1.0/person
</a:object-type>
<a:verb>
http://activitystrea.ms/schema/1.0/make-friend
</a:verb>
<a:actor>
<title>Martin</title>
</a:actor>
...
</entry>

<entry>
<title>Bill</title>
<a:object-type>
http://activitystrea.ms/schema/1.0/person
</a:object-type>
<a:verb>
http://activitystrea.ms/schema/1.0/make-friend
</a:verb>
<a:actor>
<title>Martin</title>
</a:actor>
...
</entry>

<entry>
<title>Monica</title>
<a:object-type>
http://activitystrea.ms/schema/1.0/person
</a:object-type>
<a:verb>
http://activitystrea.ms/schema/1.0/make-friend
</a:verb>
<a:actor>
<title>Martin</title>
</a:actor>
...
</entry>

</feed>

So an activity streams-aware consumer should understand this to mean:
* Martin added John as a friend.
* Martin added Bill as a friend.
* Martin added Monica as a friend.

While a traditional Atom consumer would see this as a list of items in a
feed titled "Martin's Friends" (hopefully with something pretty in the
atom:content showing the person's profile information):
* John
* Bill
* Monica

Today's applications that try to infer activities from feeds by
heuristics rather than by activity streams extensions are likely to
render this feed as something like:
* Martin posted "John" to "Martin's Friends"
* Martin posted "Bill" to "Martin's Friends"
* Martin posted "Monica" to "Martin's Friends"
...which the spec today concedes is a non-optimal but still usable
fallback when the data is being presented primarily to a human reader.


(It's interesting to note that the above is similar to the output of the
Google Contacts API, which represents a list of people as an Atom
feed... so there is precedent here for using Atom entries to represent
things other than blog entries, including people, and generalizing title
to mean "a proper noun that names this thing".)

[John Panzer]

Ah, I see -- the light dawns, finally. I now understand what you and
Monica are saying. Just as a data point, this was pretty unintuitive
to me, so you may want to consider some non-blog-post-creation
examples to make this point clear.

I do have a specific objection, now that I understand it. In the case
of blog posts/comments/etc, the action is usually creation, sometimes
editing, of the object. These two actions are pretty similar, and so
Atom didn't have any verb saying "what happened". This led to the
nearly immediate need for the Atom Tombstones extension to handle
"delete".

In the case of a friend, you're clearly not creating the actual person
being befriended. At most, you're creating a friendship edge in a
graph, or perhaps a personal contact record with info about a person.

So, I don't have any trouble conceptually mapping between the long
form activity "Bob created a blog post X" to the shorthand "Blog Post
X (authored by Bob)". The mapping "Bob friended Alice" to "Alice
(authored by Bob)" is much harder to swallow.

I'd intuitively expect to see a befriending action mapped to an Atom
entry with a fallback title of something like "Bob befriended Alice".

More specifically, if I actually want my Atom activity feeds to show
something useful in a regular feed reader, then I want the titles to
say something like "Bob friended Alice" and not just "Alice".
Especially since that's what existing translations of activities in to
RSS feeds do. So I'm still having trouble seeing the use case where
someone would actually use the shorthand for a person target -- it
doesn't appear to produce a feed that's at all useful to publish.

(The use case for Contacts is a bit different, in that the context
determines that this is a feed of people, and it never contains a
heterogenous mix of people with other things the way Activity Streams
feeds will be. They aren't intended to be useful in feed readers at
all.)



Cheers,
John

[Peter Reiser]

I am still a bit confused what the right way is to identify the author
of an information a object e.g

Use Case: Marie liked Johns "My cats Entry"

Martin Atkins proposes:


<entry>
<title>Mary liked "My cats"</title>
<activity:verb>http://.../schema/1.0/like</activity:verb>
<activity:actor>
<title>Mary</title>
....
</activity:actor>
<activity:object>
<title>My Cats</title>
<activity:object-type>
http://.../schema/1.0/blog-entry
</activity:object-type>
<author>
<name>John</name>
...
</author>
...
</activity:object>
...
</entry>

Notice that the author of the entry itself is inside activity:object,
not at the top-level entry level.

Cliqset is using
...
</activity:object>
...
<contributor>
<name>John</name>
<uri>http://cliqset.com/user/john</uri>
</contributor>
...

are both scenarios valid ?

[John Panzer]

Full of turkey (I'm U.S.) I'll dive back into this, energized by Bill's blog post: http://www.dehora.net/journal/2009/11/28/extensions-v-envelopes/ (CC'd).

I suppose this comes back to what Activity Streams is aiming for.  Is it using Atom as an envelope, a transport that lets Activity Streams be adopted more easily and get initial adoption?  Or is it extending Atom, more tightly defining the semantics of loosely defined elements like <title> and <author> when they appear within activities, but retaining compatibility with their primitive forms; adding additional links and elements as needed; but making the result still be viewed and processed by existing infrastructure in a useful way?

I think there can be useful arguments in either direction.  My personal opinion is that for Activity Streams, a format intended for syndication, extension should be preferred.  (Even though some of the element names aren't what you would've picked for a bespoke format.)

Constructive suggestion:  Use existing elements and annotate them as needed with AS-specific attributes, e.g.,:

<author as:role="actor">

  <name>Mary</name>

  ...

</author>

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

--

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.

[Monica Keller]

MySpace is using the same as what Martin proposed not contributor

We only write the owner of an object if different from the actor of
the activity

I dont really like too much having author and actor. I would prefer
that author would have been extended with all the necessary sub
elements including object type, as its not always a person, id,
profile link, avatar etc but Martin said that made for illegal atom.

This is still true right ? If so then lets continue with the actor
concept

[John Panzer]

It's perfectly legal to extend Atom with additional elements anywhere, including underneath the author element.  Blogger does this for example.  Normally this is done with elements from a custom namespace, and there's definitely no problem with that.

There is some confusion about whether standard elements in the Atom namespace itself are allowed underneath <author>, specifically and most usefully atom:link.  For example, the following is I think OK according to my reading of the Atom spec but the W3C's Feed Validator at http://validator.w3.org/feed/check.cgi flags the link as 'unknown element':

<?xml version='1.0' encoding='UTF-8'?>

<entry xmlns='http://www.w3.org/2005/Atom'>

<author>

  <name>Joe</name>

  <link rel="alternate" href="http://example.org" />

</author>

<title> </title>

<updated>2009-11-23T09:50:40.239-08:00</updated>

<id>tag:example.com,1999:383838383</id>

<content> </content>

</entry>

The non-normative Relax NG grammar in RFC 4287 explicitly forbids the use of atom:link here because it excludes anything in the atom namespace from being extension elements, e.g.:

simpleExtensionElement =
      element * - atom:* {
         text
      }

and so forth.  On the other hand the normative text of the specification doesn't say this anywhere that I can find. 

On the other hand, if I'm wrong, there is a fairly trivial workaround that lets you add links to authors anyway, assuming that you have an extension namespace to play with: Just define an as:link that means exactly the same thing as atom:link.  For example, this validates:

<?xml version='1.0' encoding='UTF-8'?>

<entry xmlns='http://www.w3.org/2005/Atom' xmlns:as='http://activititystrea.ms/ns'>

<author>

  <name>Joe</name>

  <as:link rel="alternate" href="http://example.org" />

</author>

<title> </title>

<updated>2009-11-23T09:50:40.239-08:00</updated>

<id>tag:example.com,1999:383838383</id>

<content> </content>

</entry>

However, this shouldn't be necessary.

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

--

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.

[Bill de hOra]

John Panzer wrote:
> There is some confusion about whether standard elements in the Atom
> namespace itself are allowed underneath <author>, specifically and most
> usefully atom:link. For example, the following is I think OK according
> to my reading of the Atom spec but the W3C's Feed Validator
> at http://validator.w3.org/feed/check.cgi flags the link as 'unknown
> element':
>
> <?xml version='1.0' encoding='UTF-8'?>
> <entry xmlns='http://www.w3.org/2005/Atom'>
> <author>
> <name>Joe</name>
> <link rel="alternate" href="http://example.org" />
> </author>
> <title> </title>
> <updated>2009-11-23T09:50:40.239-08:00</updated>

> <id>tag:example.com <http://example.com>,1999:383838383</id>

> <content> </content>
> </entry>
>
> The non-normative Relax NG grammar in RFC 4287 explicitly forbids the
> use of atom:link here because it excludes anything in the atom namespace
> from being extension elements, e.g.:
>
>
> simpleExtensionElement =
> element * - atom:* {
> text
> }
>
> and so forth. On the other hand the normative text of the specification
> doesn't say this anywhere that I can find.
>
> On the other hand, if I'm wrong, there is a fairly trivial workaround

You're not wrong. Atom can be used to extend Atom.

Feed validator might barf/warn on some constructs but that's typically
done to catch typos rather than invalidate markup.

The RFC's RNC is the way it is, partly because the WG missed this case
and partly because the extension constructs are simply very tricky to
define. But the RFC's RNC is not normative and as I've said here before
it's not normative *exactly* so that we wouldn't accidentally prevent
extensibility by future efforts such as Activity Streams. A number of
markup graybeards worked on Atom and we knew the limitations of the
available schema languages when we wrote the spec (for example that you
can't model Atom extensibility at using W3C Schema, and even the RNC
requires Schematron in places). We knew that the RNC couldn't represent
Atom when we designed it.

A better argument against extending atom:author is that it has fairly
specific role semantics. But since Atom doesn't have anything like a
real semantics, in practice it doesn't matter.

Bill

[Monica Keller]

Excellent I think extending author would be more intuitive than a
separate element for actor

Any oppositions ? Other than I introducing a breaking change ?

Monica

> --
>
> You received this message because you are subscribed to the Google
> Groups "Activity Streams" group.

> To post to this group, send email to activity-
> str...@googlegroups.com.

[Rob Dolin]

Hey Monica (et. al.),

I'm thinking you could potentially phase this change in by emitting data in both <entry><activity:actor> and <entry><author> for a while. This would give your partners a window in which to migrate from one to the other.

My team did this with some vestigial MSN Spaces elements in our Windows Live Spaces RSS 2.0 feeds.

FWIW--
--Rob

-----Original Message-----
From: Monica Keller [mailto:monica...@gmail.com]

To post to this group, send email to activity...@googlegroups.com.

[Martin Atkins]

Monica Keller wrote:
> Excellent I think extending author would be more intuitive than a
> separate element for actor
>

We still need to address the difference between a person represented as
an author (whose name will be in atom:name) vs. a person represented as
an entry (whose name will be in atom:title). We also need to consider
how this impacts the activity:subject element at the feed level.

My consumer implementation uses the same object parser regardless of
whether the object it's processing is the object, the target, the actor
or the feed's subject. If we're going to introduce a special case for
actor where atom:title is replaced with atom:name then that will require
some refactoring. How have other folks implemented this?

[Dan Brickley]

On Mon, Nov 30, 2009 at 2:24 AM, Martin Atkins <ma...@degeneration.co.uk> wrote:
> Monica Keller wrote:
>> Excellent I think extending author would be more intuitive than a
>> separate element for actor
>>
>
> We still need to address the difference between a person represented as
> an author (whose name will be in atom:name) vs. a person represented as
> an entry (whose name will be in atom:title). We also need to consider
> how this impacts the activity:subject element at the feed level.

Will the JSON version inherit these subtleties, or can you afford some
variation between the Atom and JSON versions of activitystreams to
allow more internal consistency within each?

cheers,

Dan

[John Panzer]

Without looking at the code it's difficult to give a real opinion.  But having done similar stuff for RSS vs. Atom parsing I don't think it's a huge deal to define some simple rules.  For example, if something has atom:name, use that; if not, look for atom:title.  On output, do as the Romans do, and output the appropriate form for the current context (title in an atom:entry, name in an atom:author or atom:contributor).

Then the JSON format could just pick one or the other.

(Note:  I'm still not sure I accept the premise that AS people need to be represented as top level entries, because I don't understand the use case for it.)

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

--

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.

[Martin Atkins]

I don't think it's really clear so far exactly what JSON activity
streams will look like, but here's what I've been thinking so far:

* The JSON serialization will be much closer to the abstract data
model of activity streams than the Atom serialization is. That means
that an activity stream is a list of objects that each represent a
single activity.

* An activity has the following properties:
* One actor
* One object
* Zero or one targets
* Zero or one "sources"
* One timestamp
* An array of verb URIs

* The base type for objects has the following properties:
* one id
* one displayName
* one permalinkUrl
* one published time
* An array of object type URIs

This base set of properties is the minimum necessary to translate the
fallback behavior for unknown types that we use for Atom. (use the title
and the permalink URL to make a link to the object without saying
anything about its type.)

* Other object types extend the object base type by adding additional
properties to the base set above.

For example, the "person" type might add an array of avatars and might
specify that the displayName will contain a name by which the user can
be referred to.

So to answer your question, I do hope that the JSON serialization will
be far more normal and consistent in data model than the Atom
serialization, since we're not constrained by the requirement to provide
sane output to non-activity feed consumers.

I have begun experimenting with the JSON seralization in the toy
application I've been working on with one of my co-workers at Six Apart,
"giraffe":
http://github.com/markpasc/giraffe

Here's how the experimental JSON implementation is representing persons:

{
"avatars": [
{
"width": "80",
"href":
"http://dynamic.cliqset.com/avatar/apparentlymart?s=80",
"type": "image/png",
"height": "80"
},
{
"width": "120",
"href":
"http://dynamic.cliqset.com/avatar/apparentlymart?s=120",
"type": "image/png",
"height": "120"
},
{
"width": "200",
"href":
"http://dynamic.cliqset.com/avatar/apparentlymart?s=200",
"type": "image/png",
"height": "200"
}
],
"permalinkUrl": "",
"displayName": "",
"id": "apparentlymart",
"objectTypes": [
"http://activitystrea.ms/schema/1.0/person"
]
}

(This is actually the best of a bunch of bad examples because none of
the publically-available activity streams feeds do people quite right at
the moment. Cliqset puts my username in the id field where really a URI
would be expected and leaves out title, where we'd expect to find my name.)

Here's the beginnings of a spec, too:
http://martin.atkins.me.uk/specs/activitystreams/jsonactivity