deconstructing activities

[Erik Wilde]

hello.

after reading through
http://tools.ietf.org/html/draft-snell-activitystreams-08#appendix-C, it
seems to me that this particular set of rules might be better expressed
in a stricter form. i haven't tried to do it, but i am wondering if
anybody might also think that an HTML5-ish writing style (which often is
structured prose that looks a whole lot like an implementation sketch)
could help. it might make it more likely that different implementations
end up with the same interpretation of activities when it comes to
activity linguistic forms, and activity durations.

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

[Benjamin Goering]

I think a reference implementation would be sufficient too, even without a change to the spec writing style.

https://github.com/gobengo/activity-phraser

It's quite naive and just for fun right now, but now that I see this appendix to the spec, I can make it fancier.

And a dependant Web Component that takes a feed of past/future activity streams and renders a list of phrases.

https://github.com/gobengo/activity-phrase-feed

[Erik Wilde]

hello benjamin.

On 2014-07-08, 10:44 , Benjamin Goering wrote:
> I think a reference implementation would be sufficient too, even without
> a change to the spec writing style.
> https://github.com/gobengo/activity-phraser
> It's quite naive and just for fun right now, but now that I see this
> appendix to the spec, I can make it fancier.

personally, i think that a spec should be self-contained and be
sufficient to implement it. and i am not saying with certainty that the
current text contains errors or is not sufficient to implement. it just
seems to me that a more structured writing style might help both with
being more clear in expressing what the spec is saying, and making it
more easy for readers to understand what the spec is asking for.

[James M Snell]

That's largely why this section is included as an appendix... as is,
it's difficult to implement yet. There are a broad variety of
considerations that need to be taken into account that I just haven't
been able to get around documenting. The fundamental idea however
ought to be clear: even though the basic activity stream statement is
fundamentally intended to be machine-readable, we need a clear
algorithm for producing a human-readable form. In order to do that
consistently, we need the ability to relate the machine readable
constructs back into linguistic forms. There are two things that make
this extremely difficult to do: 1) the inherent flexibility of the
activity streams format and 2) human speech is annoyingly
inconsistent. Which is a long way of saying: while I agree with Erik
on this, it's going to be extremely difficult to get it right.

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

On 2014-07-08, 16:59, James M Snell wrote:
> That's largely why this section is included as an appendix... as is,
> it's difficult to implement yet. There are a broad variety of
> considerations that need to be taken into account that I just haven't
> been able to get around documenting.

i am sure about that. and it's not meant of a criticism of what's
currently there. but it's maybe one of those places where once the WG is
up and running, some shared effort would be good to make sure that the
spec gets a bit easier to read and implement.

> The fundamental idea however
> ought to be clear: even though the basic activity stream statement is
> fundamentally intended to be machine-readable, we need a clear
> algorithm for producing a human-readable form. In order to do that
> consistently, we need the ability to relate the machine readable
> constructs back into linguistic forms. There are two things that make
> this extremely difficult to do: 1) the inherent flexibility of the
> activity streams format and 2) human speech is annoyingly
> inconsistent. Which is a long way of saying: while I agree with Erik
> on this, it's going to be extremely difficult to get it right.

there's no doubt about that. and maybe there's also some combinations
where the "mapping algorithm" would kind of give up and result in a
minimal form, because it's impossible to define a generic mapping. but
in the end, this is a question about what an activity actually "means"
(to some extent), right? then there ought to be some way how this is
defined, and how this is mapped to something that's at least in part a
human-readable representation of the machine-readable version.