Crediting service providers or sources

[Chris Messina]

One outstanding issue that we need to address is how to cite sources (or services or tools) that are used to generate activities. Now, ATOM already provides for a "source" element, as well as a "generator" element, but both of those attributes do very different things and actually don't help us much. Specifically:

* the atom:source is used when splicing feeds together and resyndicating the results... <atom:source> is used as a bucket to copy the original metadata from the *source* feed so that downstream aggregators can use the original data.

* <atom:generator> is a simpler mechanism that is similar to the user-agent string in a browser. It's mostly used to help debug malformed feeds...

More recently Cliqset has proposed a <service:provider> element, and I believe that's what this spec by Martin captures:

http://martin.atkins.me.uk/specs/activitystreams/provider 

Essentially it provides another ATOM extension that defines <service:provider> as having three elements:

• <atom:name>
• <atom:icon>
• <atom:uri>

I think these are the right attributes, but feel that rather than creating another extension, this should just be baked into the core ActivityStreams spec as: <activity:service>. We can then use <name>, <icon>, and <uri> as defined by ATOM.

I've written up this proposal on the wiki:

http://wiki.activitystrea.ms/Crediting-Sources

I would like to include this in the 1.0 version of the spec by folding in much of Martin's service-provider draft spec.

Any thoughts or improvements?

Chris

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

On 03/02/2010 11:01 PM, Chris Messina wrote:
>
> More recently Cliqset has proposed a <service:provider> element, and I
> believe that's what this spec by Martin captures:
>
> http://martin.atkins.me.uk/specs/activitystreams/provider
>
> Essentially it provides another ATOM extension that defines
> <service:provider> as having three elements:
>

> * <atom:name>
> * <atom:icon>
> * <atom:uri>

>
> I think these are the right attributes, but feel that rather than
> creating another extension, this should just be baked into the core
> ActivityStreams spec as: <activity:service>. We can then use <name>,
> <icon>, and <uri> as defined by ATOM.
>

That spec is designed to be used in all Atom feeds, not just activity
streams ones. That is why it lives in its own namespace.

It has an activitystrea.ms namespace URI just because it was a
convenient place to define it without having to go through political
machinations as would be necessary to get it on something like
purl.org/syndication .

[Monica Keller]

Agreed that it would be useful for publishers to syndicate the source
service and possibly the tool for
1- Attribution
2- Microsyntax parsing (Making links to @'s, #'s) which is generally
specific to the provider. Eg: Twitter, Buzz
This should be done in separate fields.
As you know, I do think atom:source inside the entry can be extended
to convey the source service but I am by no means an atom expert. I am
just going by this definition http://tools.ietf.org/html/rfc4287#section-4.2.11
and some examples in the wild (pubsubhubbub)
If the publisher knows not only the source but also the id for the
original entry then they should use the cross posting specification
and allow consumers to easily dedup see http://martin.atkins.me.uk/specs/atomcrosspost

Also I am not sure why we cannot use "generator" for the tool, this is
the user-agent exactly. Ex: Tweetdeck v 1.0.8 which

See description below. There is no constraint on how the content is
"copied" -- I think this will work great

4.2.11. The "atom:source" Element

If an atom:entry is copied from one feed into another feed, then
the
source atom:feed's metadata (all child elements of atom:feed other
than the atom:entry elements) MAY be preserved within the copied
entry by adding an atom:source child element, if it is not already
present in the entry, and including some or all of the source
feed's
Metadata elements as the atom:source element's children. Such
metadata SHOULD be preserved if the source atom:feed contains any
of
the child elements atom:author, atom:contributor, atom:rights, or
atom:category and those child elements are not present in the
source
atom:entry.

atomSource =
element atom:source {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId?
& atomLink*
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle?
& atomUpdated?
& extensionElement*)
}

On Mar 2, 11:01 pm, Chris Messina <chris.mess...@gmail.com> wrote:
> One outstanding issue that we need to address is how to cite sources (or
> services or tools) that are used to generate activities. Now, ATOM already
> provides for a "source" element, as well as a "generator" element, but both
> of those attributes do very different things and actually don't help us
> much. Specifically:
>
> * the atom:source is used when splicing feeds together and resyndicating the
> results... <atom:source> is used as a bucket to copy the original metadata
> from the *source* feed so that downstream aggregators can use the original
> data.
> * <atom:generator> is a simpler mechanism that is similar to the user-agent
> string in a browser. It's mostly used to help debug malformed feeds...
>
> More recently Cliqset has proposed a <service:provider> element, and I
> believe that's what this spec by Martin captures:
>
> http://martin.atkins.me.uk/specs/activitystreams/provider
>
> Essentially it provides another ATOM extension that defines
> <service:provider> as having three elements:
>

>    - <atom:name>
>    - <atom:icon>
>    - <atom:uri>

[Monica Keller]

Ok chatted with Martin and he explained that source maps to an
individual feed. Ex: Monica's Twitter Feed not Twitter. Agreed. So the
title is not for the service
So we agreed that we should model the service object and be able to
place this object at the feed level or inside the source for the case
where the original post was made on another service. This is the most
complete solution and compatible with what you are proposing Chris

The link rel alternate on the source of type text/html should point to
my twitter page and the link in the service:provider would point to
twitter.

On Mar 3, 10:24 am, Monica Keller <monica.kel...@gmail.com> wrote:
> Agreed that it would be useful for publishers to syndicate the source
> service and possibly the tool for
> 1- Attribution
> 2- Microsyntax parsing (Making links to @'s, #'s) which is generally
> specific to the provider. Eg: Twitter, Buzz
> This should be done in separate fields.
> As you know, I do think atom:source inside the entry can be extended
> to convey the source service but I am by no means an atom expert. I am

> just going by this definitionhttp://tools.ietf.org/html/rfc4287#section-4.2.11

> and some examples in the wild (pubsubhubbub)
> If the publisher knows not only the source but also the id for the
> original entry then they should use the cross posting specification

> and allow consumers to easily dedup seehttp://martin.atkins.me.uk/specs/atomcrosspost

[Chris Messina]

Ok, that sounds good. 

While I'm not completely opposed to having a separate extension for services, I'm worried about causing confusion here — unless there simply needs to be an editor's draft that pulls together a number of separate specs in a way that developers who are new to all this could actually get started and finish implementing something without tracking down half a dozen specs.

I guess I'm also not completely familiar with ATOM tradition — and how much these kinds of discreet needs should be broken out.

I'd like to see privacy, groups, service providers — and at some point — actions links represented in ActivityStreams. Should each be a separate stand-alone spec?

Chris

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

[Martin Atkins]

On 03/03/2010 11:48 AM, Chris Messina wrote:
> Ok, that sounds good.
>
> While I'm not completely opposed to having a separate extension for

> services, I'm worried about causing confusion here � unless there simply

> needs to be an editor's draft that pulls together a number of separate
> specs in a way that developers who are new to all this could actually
> get started and finish implementing something without tracking down half
> a dozen specs.
>

> I guess I'm also not completely familiar with ATOM tradition � and how

> much these kinds of discreet needs should be broken out.
>

> I'd like to see privacy, groups, service providers � and at some point �

> actions links represented in ActivityStreams. Should each be a separate
> stand-alone spec?
>

I think if something is conceivably useful in generic Atom feeds then it
ought to be a separate spec. Such specs might conceivably go into the
IETF at some point just as Threading Extensions, Tombstones, and Feed
Paging and Archiving did.

The AtomActivity spec can and probably should recommend using the
service provider metadata extension to identify the service that the
activity was performed on. I think right now the poor interconnection
between these specs is mainly just because none of them are published
and thus none of them can cite any other one without creating a
dependency that they all be finished and published at the same time,
since a published spec can't sensibly cite a draft spec.

[John Panzer]

Query:  The service:provider spec states that it SHOULD be placed within atom:source for re-syndicated entries.  Fine as far as it goes, but what about re-syndicated entries using atom:crosspost and _not_ using atom:source because they are not preserving atom:id?  They don't have atom:source, they can't use atom:feed, so... ?

I like the proposal.  I'm not crazy about the name "service provider" as it's so generic.  "Entry generator" would be more specific.  

I would very much like the service provider's URI to be LRDD (discovery) enabled as it's so much more useful that way; clearly doesn't need to be in the spec, just raising attention here.

On Wed, Mar 3, 2010 at 3:50 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:

On 03/03/2010 11:48 AM, Chris Messina wrote:

Ok, that sounds good.

While I'm not completely opposed to having a separate extension for

services, I'm worried about causing confusion here — unless there simply

needs to be an editor's draft that pulls together a number of separate
specs in a way that developers who are new to all this could actually
get started and finish implementing something without tracking down half
a dozen specs.

I guess I'm also not completely familiar with ATOM tradition — and how

much these kinds of discreet needs should be broken out.

I'd like to see privacy, groups, service providers — and at some point —

actions links represented in ActivityStreams. Should each be a separate
stand-alone spec?

I think if something is conceivably useful in generic Atom feeds then it ought to be a separate spec. Such specs might conceivably go into the IETF at some point just as Threading Extensions, Tombstones, and Feed Paging and Archiving did.

The AtomActivity spec can and probably should recommend using the service provider metadata extension to identify the service that the activity was performed on. I think right now the poor interconnection between these specs is mainly just because none of them are published and thus none of them can cite any other one without creating a dependency that they all be finished and published at the same time, since a published spec can't sensibly cite a draft spec.

--