Activity/action expiration & concurrent access

[Laurent-Walter Goix]

Hi,

In our usage of the AS and action handlers for smart objects we figured out the following needs that we believe could be of generic interest for the AS 2.0 spec:

- identify an expiration date for the activity and/or action: a generic "expires" property is useful to represent a dateTime until which the activity itself, or the specific action, should be considered valid. After this time, a client reading such information should (or must) ignore it. besides use cases such as snapchat, this becomes useful to fix a deadline for actions within an activity that may have no sense after that time

- include a state/etag property into objects that can be used for concurrent access: whenever such a property is present, any further activity on this object should include that same state value that was received. in case of omission or mismatch with the current/latest state of that object the inbound activity should be ignored. This is particularly useful when such activities correspond to commands to objects, but may benefit other use cases...

Are these of interest of other people / use cases?

Walter

[James M Snell]

Having a generalized expiration timestamp is certainly useful, I
think, and well worth having. To be honest, having both "validFrom"
and "validUntil" properties makes the most sense.

{
"objectType": "Offer",
"validFrom": "2014-05-27T12:00:00Z",
"validUntil": "2014-05-28T12:00:00Z"
}

We would need to carefully scope how these relate to (and possibly
overlap with in some cases) the startTime and endTime properties but
that is straightforward.

State is a tricky one, and not something that can be easily applied in
a generic way. In the action handlers specification, we can easily add
an "etag" property on the HttpActionHandler or ViewActionHandler
object types and define how that translates into If-Match or
If-None-Match, but providing a "state" for any arbitrary object type
is difficult.

> --
> You received this message because you are subscribed to the Google Groups
> "Activity Streams" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to activity-strea...@googlegroups.com.
> To post to this group, send email to activity...@googlegroups.com.
> Visit this group at http://groups.google.com/group/activity-streams.
> For more options, visit https://groups.google.com/d/optout.

[Erik Wilde]

hello.

reading through the latest AS draft
(http://tools.ietf.org/html/draft-snell-activitystreams-08), and
focusing on how to link web resources together, there are some things i
was wondering about:

- http://tools.ietf.org/html/draft-snell-activitystreams-08#section-3.4
talks about "RFC 5988 link relations" and seems to assume mostly what
RFC 5988 calls "registered relation types"? i am wondering whether all
AS constructs work robustly when "extension relation types", i.e. URIs,
are used as link relation types. specifically, this could mean that the
property name of a link would be a URI. i think it is very important to
align AS with RFC5988 web linking, but maybe both the text and the
examples should specifically mention both kinds of link relations?

- regarding the link-related draft text, here's another thing i am
wondering about. the text says: 'Within an object, in the absence of a
specific "rel" property within the link object itself, the name of the
property whose value is a link serves as the "link relation".' so how
would one *know* that a property's value is a link? it cannot be done by
just inspecting the value, right? other properties might have URI values
as well, and a link's URI might be relative and not *look* like a URI,
right?

- at a more abstract level, i am wondering how/if complete AS resources
can be linked. what i am talking about is a kind of atom:feed/atom:link
construct, which allows to represent ways in which a resource (i.e., a
complete AS) is related to other web resources (as opposed to how a
specific activity is related to something else). in our work on feeds
(which we want to move to AS), this kind of information proves to be
very valuable, but of course it also complicates matters since then
there has to be a model for how to "inherit" this information. atom's
way of doing this certainly is one of the more byzantine parts of the
atom spec: http://tools.ietf.org/html/rfc4287#section-4.2.11

thanks a lot and cheers,

dret.

--
erik wilde | mailto:dr...@berkeley.edu - tel:+1-510-2061079 |
| UC Berkeley - School of Information (ISchool) |
| http://dret.net/netdret http://twitter.com/dret |

[James M Snell]

On Tue, May 27, 2014 at 11:15 AM, Erik Wilde <dr...@berkeley.edu> wrote:
> hello.
>
> reading through the latest AS draft
> (http://tools.ietf.org/html/draft-snell-activitystreams-08), and focusing on
> how to link web resources together, there are some things i was wondering
> about:
>
> - http://tools.ietf.org/html/draft-snell-activitystreams-08#section-3.4
> talks about "RFC 5988 link relations" and seems to assume mostly what RFC
> 5988 calls "registered relation types"? i am wondering whether all AS
> constructs work robustly when "extension relation types", i.e. URIs, are
> used as link relation types. specifically, this could mean that the property
> name of a link would be a URI. i think it is very important to align AS with
> RFC5988 web linking, but maybe both the text and the examples should
> specifically mention both kinds of link relations?
>

Yes, the intention is that *any* link relation can be used as a
property in an AS 2.0 document so long as the link relation does not
conflict with an existing core property value. So you can use a
URI/IRI form as a property name.

> - regarding the link-related draft text, here's another thing i am wondering
> about. the text says: 'Within an object, in the absence of a specific "rel"
> property within the link object itself, the name of the property whose value
> is a link serves as the "link relation".' so how would one *know* that a
> property's value is a link? it cannot be done by just inspecting the value,
> right? other properties might have URI values as well, and a link's URI
> might be relative and not *look* like a URI, right?
>

In general, a link value would include either a "url" or "id"
property. The "url" *should* be an absolute URI/IRI. The "id" *must*
be an absolute URI/IRI. That said, however, Link Values are not
strongly typed. So, in the following:

{
"a": "foo",
"b": "http://example.org/foo",
"c": {
"url": "http://example.org/foo"
},
"d": {
"id": "http://example.org/foo"
},
"e": {
"displayName": "foo"
}
}

Any of these (properties "a" through "e") can be processed as Link
Values but can be processed in other ways also. The property "a", for
instance, can be processed as a Link Value if you choose to treat the
string value as a relative reference. There's no requirement that you
have to treat it that, way, however. You'll have to understand the
meaning of the "a" property.

> - at a more abstract level, i am wondering how/if complete AS resources can
> be linked. what i am talking about is a kind of atom:feed/atom:link
> construct, which allows to represent ways in which a resource (i.e., a
> complete AS) is related to other web resources (as opposed to how a specific
> activity is related to something else). in our work on feeds (which we want
> to move to AS), this kind of information proves to be very valuable, but of
> course it also complicates matters since then there has to be a model for
> how to "inherit" this information. atom's way of doing this certainly is one
> of the more byzantine parts of the atom spec:
> http://tools.ietf.org/html/rfc4287#section-4.2.11
>

The idea has been to strike a balance between the kind of strong
typing provided by Atom's link element and the loosely defined duck
typing allowed by JSON in general. We can layer in stronger typing
using JSON-LD constructs, if necessary. Overall, however, in AS 2.0,
if it looks like a duck...

- James

> thanks a lot and cheers,
>
> dret.
>
> --
> erik wilde | mailto:dr...@berkeley.edu - tel:+1-510-2061079 |
> | UC Berkeley - School of Information (ISchool) |
> | http://dret.net/netdret http://twitter.com/dret |
>

[Erik Wilde]

hello james.

thanks for the quick response!

On 2014-05-27, 11:28 , James M Snell wrote:
> On Tue, May 27, 2014 at 11:15 AM, Erik Wilde <dr...@berkeley.edu> wrote:
>> - http://tools.ietf.org/html/draft-snell-activitystreams-08#section-3.4
>> talks about "RFC 5988 link relations" and seems to assume mostly what RFC
>> 5988 calls "registered relation types"? i am wondering whether all AS
>> constructs work robustly when "extension relation types", i.e. URIs, are
>> used as link relation types. specifically, this could mean that the property
>> name of a link would be a URI. i think it is very important to align AS with
>> RFC5988 web linking, but maybe both the text and the examples should
>> specifically mention both kinds of link relations?
> Yes, the intention is that *any* link relation can be used as a
> property in an AS 2.0 document so long as the link relation does not
> conflict with an existing core property value. So you can use a
> URI/IRI form as a property name.

that's very good to hear. i would suggest to make that explicit in the
text and to add examples that use the URI form of relation types. also,
if there's a test suite somewhere (is there?), it should make sure to
always cover these two variations.

>> - regarding the link-related draft text, here's another thing i am wondering
>> about. the text says: 'Within an object, in the absence of a specific "rel"
>> property within the link object itself, the name of the property whose value
>> is a link serves as the "link relation".' so how would one *know* that a
>> property's value is a link? it cannot be done by just inspecting the value,
>> right? other properties might have URI values as well, and a link's URI
>> might be relative and not *look* like a URI, right?
> In general, a link value would include either a "url" or "id"
> property.

but looking at it the other way around: in order to figure out that
something indeed *is* a link, is it sufficient to look for either
property and then conclude that only links will have those?

> The "url" *should* be an absolute URI/IRI. The "id" *must*
> be an absolute URI/IRI. That said, however, Link Values are not
> strongly typed. So, in the following:
> {
> "a": "foo",
> "b": "http://example.org/foo",
> "c": {
> "url": "http://example.org/foo"
> },
> "d": {
> "id": "http://example.org/foo"
> },
> "e": {
> "displayName": "foo"
> }
> }
> Any of these (properties "a" through "e") can be processed as Link
> Values but can be processed in other ways also. The property "a", for
> instance, can be processed as a Link Value if you choose to treat the
> string value as a relative reference. There's no requirement that you
> have to treat it that, way, however. You'll have to understand the
> meaning of the "a" property.

i guess this is where the bigger question then becomes how the various
a's that may float around can be distinguished. this of course brings up
the (careful, dirty word coming up!) interesting topic of: namespaces.
on some levels (verbs and object types), there is some explicit
extension/openness model. it would be interesting to discuss how this
does or does not apply to the question of figuring out if the above "a"
property is or isn't a link.

>> - at a more abstract level, i am wondering how/if complete AS resources can
>> be linked. what i am talking about is a kind of atom:feed/atom:link
>> construct, which allows to represent ways in which a resource (i.e., a
>> complete AS) is related to other web resources (as opposed to how a specific
>> activity is related to something else). in our work on feeds (which we want
>> to move to AS), this kind of information proves to be very valuable, but of
>> course it also complicates matters since then there has to be a model for
>> how to "inherit" this information. atom's way of doing this certainly is one
>> of the more byzantine parts of the atom spec:
>> http://tools.ietf.org/html/rfc4287#section-4.2.11
> The idea has been to strike a balance between the kind of strong
> typing provided by Atom's link element and the loosely defined duck
> typing allowed by JSON in general. We can layer in stronger typing
> using JSON-LD constructs, if necessary. Overall, however, in AS 2.0,
> if it looks like a duck...

not sure this is what i was talking about. what i am looking for is the
ability for a publisher of activities to expose information about that
particular *stream*. think of it as the ability to "link a stream"
instead of just "linking an activity". we have found this to be very
helpful when using feeds, for example in spatial settings where a
particular feed can link to "zoom out" and "zoom in" feeds, allowing a
consumer to navigate related information sources. another example is to
link to a query/filter resource that allows a consumer to choose a
different set of activities. generally speaking, the goal is to link
information resources (in this case, activity streams), and i am
wondering how to best do that.

thanks and cheers,

[Laurent-Walter Goix]

Il giorno martedì 27 maggio 2014 18:25:17 UTC+2, James M Snell ha scritto:

Having a generalized expiration timestamp is certainly useful, I
think, and well worth having. To be honest, having both "validFrom"
and "validUntil" properties makes the most sense.

{
  "objectType": "Offer",
  "validFrom": "2014-05-27T12:00:00Z",
  "validUntil": "2014-05-28T12:00:00Z"
}

We would need to carefully scope how these relate to (and possibly
overlap with in some cases) the startTime and endTime properties but
that is straightforward.

validity nicely extends the pure concept of expiration with a starting date, focusing on a period of time during which the activity/object is to be considered valid (and for example should be ignored outside/after that period), rather than the pure duration of the activity. I also agree that distinct property names would clarify the semantics and avoid confusion in overloading both concepts: events may be more related to start/end concepts, bids/offers may use them in alternative, but commands for example, or simple notes/images etc (see snapchat) would more likely fit "validity" concepts. i am not sure if any activity would use both concepts at the same time but they may be.

State is a tricky one, and not something that can be easily applied in
a generic way. In the action handlers specification, we can easily add
an "etag" property on the HttpActionHandler or ViewActionHandler
object types and define how that translates into If-Match or
If-None-Match, but providing a "state" for any arbitrary object type
is difficult.

i agree they may be distinct issues.
etag may be quite straightforward as you said and solve the issue of concurrent access: this can easily map to the http handler but i would suggest possibly to make it indendepent from the specific handler (e.g. it could be conveyed back in a resulting activity in case of socialactionhandler for example).
i conceived "state" mainly as per the oauth2 concept of the state parameter, which could be any opaque token used to maintain state between an activity and a subsequent action (no matter which handler uses it), but also for security purpose across sites.

walter

[Erik Wilde]

hello.

On 2014-05-27, 21:32 , Erik Wilde wrote:
> not sure this is what i was talking about. what i am looking for is the
> ability for a publisher of activities to expose information about that
> particular *stream*. think of it as the ability to "link a stream"
> instead of just "linking an activity". we have found this to be very
> helpful when using feeds, for example in spatial settings where a
> particular feed can link to "zoom out" and "zoom in" feeds, allowing a
> consumer to navigate related information sources. another example is to
> link to a query/filter resource that allows a consumer to choose a
> different set of activities. generally speaking, the goal is to link
> information resources (in this case, activity streams), and i am
> wondering how to best do that.

in addition to this, when thinking about activity streams "at the
source" (i.e., not downstream where activities from various sources may
get mixed together), a stream-level capability for representing some
aspects of activities could save a lot of space. you could think of it
as a possible "default" that's used for activities in a stream unless an
activity overrides the default. this does make the processing model a
bit more complicated, but on the other hand provides convenient ways in
which "repetitive" activities can avoid a lot of redundancy. one way to
think of this could be to think of atom's feed-level elements, the
atom:source element, and the ways in which these concepts interact.

any opinions about how useful such a feature might be?