A few questions about the activity extension spec

[Sylvain Hellegouarch]

Hi all,

Section 4.4 says:

An activity feed processor SHOULD use the most specific verb it
understands within each entry.

Any hint on what consumers ought to do when they understand several
verbs at the same specific level? Is it actually legit to have more
than one verb at given level?
Also, how to convey the specialization hierarchy? Is it an out of band
information (like an API documentation would explain verbs and their
relationship to one another).

Section 4.5 says:

An activity entry and its associated object entry MUST NOT share the
same atom:id value.

Why such a constraint?

Section 6.1 says:

When the activity:subject extension element is used, the value of its
atom:id element can be compared with the corresponding atom:id
elements in activity:object, activity:actor and activity:target
entry-level elements to determine which role the feed's actor played
in an activity.

"compared" and "determine" are quite meaningless as it is. How to
compare two IRI in this context? What is there to determine precisely?

- Sylvain

[Martin Atkins]

Hi Sylvain. Thanks for taking the time to send your feedback and questions.

On 12/29/2009 12:50 PM, Sylvain Hellegouarch wrote:
>
> Section 4.4 says:
>
> An activity feed processor SHOULD use the most specific verb it
> understands within each entry.
>
> Any hint on what consumers ought to do when they understand several
> verbs at the same specific level? Is it actually legit to have more
> than one verb at given level?
> Also, how to convey the specialization hierarchy? Is it an out of band
> information (like an API documentation would explain verbs and their
> relationship to one another).
>
>

Section 4.4 also states:
Where multiple verbs are used, all verbs MUST be generalizations or
specializations of one another.

The intent of this is to prohibit two verbs at the same level in the
hierarchy. Certainly in my implementation the result would be undefined
if there were two equally-specialized verbs, since the selection is done
by sorting the list by specificity and taking the item at the end of the
list.

At present the verb and object type heirarchies are not machine readable
and are defined only by specification. Implementations generally contain
information about the heirarchy of the types they are interested in. It
may be interesting in future to define a format that allows these to be
described in a machine-readable way, but that is not a goal for this
first iteration.

>
> Section 4.5 says:
>
> An activity entry and its associated object entry MUST NOT share the
> same atom:id value.
>
> Why such a constraint?
>

Two entries with the same id are assumed, per the definition of the id
element, to be the same entry. Implementations often use id as part of a
primary key which may prevent two entries with the same id from existing
in the same feed, or cause the second instance to be interpreted as an
edit of the first.

>
> Section 6.1 says:
>
> When the activity:subject extension element is used, the value of its
> atom:id element can be compared with the corresponding atom:id
> elements in activity:object, activity:actor and activity:target
> entry-level elements to determine which role the feed's actor played
> in an activity.
>
> "compared" and "determine" are quite meaningless as it is. How to
> compare two IRI in this context? What is there to determine precisely?
>

I agree that this is not defined well enough. I'll make a note to
rewrite this sentence in a future revision. Thanks.

The intent is to do a character-by-character comparison of the id IRI to
determine whether an inline object is the same object as the feed's
subject. This allows one to determine whether the feed's subject was the
actor, object or target of a particular activity within the feed.

One example of an activity where the subject may not be the actor is
when a friend tags me in a photo; it is a popular convention that on
social networks this activity shows up in contexts where I am the
subject, such as my profile page.

[Monica Keller]

> Section 4.5 says:
> An activity entry and its associated object entry MUST NOT share the
> same atom:id value.
> Why such a constraint?

To be able to reference them individually and allow independent
manipulation... I can delete the activity from my stream and not have
to delete the primary object in the activity

The id or natural key for an activity normally includes the actor id,
the verb, the object type, object id and date time the activity was
done
The id or natural key for an object normally includes the owner id,
object type and object id

Thanks for covering all the other questions Mart

[Monica Keller]

Oh just to clarify im not stating that the ids have to be natural keys
you can use guids if you want.

> > subject, such as my profile page.- Hide quoted text -
>
> - Show quoted text -

[Sylvain Hellegouarch]

Hi Martin,

Thanks for the feedback. Can"t say I'm as swift as you were.

>
> Section 4.4 also states:
> Where multiple verbs are used, all verbs MUST be generalizations or
> specializations of one another.
>
> The intent of this is to prohibit two verbs at the same level in the
> hierarchy. Certainly in my implementation the result would be undefined
> if there were two equally-specialized verbs, since the selection is done
> by sorting the list by specificity and taking the item at the end of the
> list.
>
> At present the verb and object type heirarchies are not machine readable
> and are defined only by specification. Implementations generally contain
> information about the heirarchy of the types they are interested in. It
> may be interesting in future to define a format that allows these to be
> described in a machine-readable way, but that is not a goal for this
> first iteration.

Seems fair enough.

> Two entries with the same id are assumed, per the definition of the id
> element, to be the same entry. Implementations often use id as part of a
> primary key which may prevent two entries with the same id from existing
> in the same feed, or cause the second instance to be interpreted as an
> edit of the first.

I think what confused me was that I wouldn't have expected activity
entries and object entries to be part of the same feed, therefore
being able to have the same id. That being said, it wouldn't make much
more sense anyways so it's sensible indeed to explicitly prevent them
from sharing a given id.

> I agree that this is not defined well enough. I'll make a note to
> rewrite this sentence in a future revision. Thanks.
>
> The intent is to do a character-by-character comparison of the id IRI to
> determine whether an inline object is the same object as the feed's
> subject. This allows one to determine whether the feed's subject was the
> actor, object or target of a particular activity within the feed.
>
> One example of an activity where the subject may not be the actor is
> when a friend tags me in a photo; it is a popular convention that on
> social networks this activity shows up in contexts where I am the
> subject, such as my profile page.

The idea is sensible but the methodology is probably a bit weak. I
would have probably rather preferred using the atom:category element
for that purpose. It's an under appreciated element when it can convey
a very rich semantic.

Thanks for the feedback,
- Sylvain