Issue 6: Event Object Type
Monica Keller
Examples from MySpace are:
$actor is hosting $eventName on $eventDate (verb = post)
$actor is attending $eventName on $eventDate (verb = join)
Since events are common in the wild there is already a format for
representing many of their properties:
See http://tools.ietf.org/html/draft-royer-calsch-xcal-03
And http://microformats.org/wiki/hcal
Proposal:
<activity:object>
<activity:object-
type>http://activitystrea.ms/schema/1.0/Event</activity:object-type>
<id>tag:myspace.com,2009:/Event/1234/11104915</id>
<title>Golden Dragon Festival & Parade</title>
<link rel="alternate" type="text/html"
href="http://events.myspace.com/index.cfm?
fuseaction=events.detail&eventID=11104915" />
<vevent xmlns="urn:ietf:params:xml:ns:xcal">
<uid>tag:myspace.com,2009:/Event/1234/11104915</uid>
<summary>Universal Bar & Grill</summary>
<dtStart>2009-03-15T05:30:00Z</dtStart>
<location>4093 Lankershim Blvd., North Hollywood, 91602,
US</location>
</vevent>
</activity:object>
Note that
>>LOCATION MAY be represented by an adr
Also there is some duplication of information (title and id) but
vCalendar
parsers could treat an activitystrea.ms atom feed of events as a
calendar
if we mantain this required fields
Martin Atkins
mailing list *before* entering them as issues so that the issue tracker
is for tracking things that have been decided rather than things that
are yet to be decided. However, events are a non-contentious event type
that we've been discussing for a while so it probably doesn't hurt in
this case.)
Monica Keller wrote:
> <activity:object>
> <activity:object-
> type>http://activitystrea.ms/schema/1.0/Event</activity:object-type>
> <id>tag:myspace.com,2009:/Event/1234/11104915</id>
> <title>Golden Dragon Festival & Parade</title>
> <link rel="alternate" type="text/html"
> href="http://events.myspace.com/index.cfm?
> fuseaction=events.detail&eventID=11104915" />
> <vevent xmlns="urn:ietf:params:xml:ns:xcal">
> <uid>tag:myspace.com,2009:/Event/1234/11104915</uid>
> <summary>Universal Bar & Grill</summary>
> <dtStart>2009-03-15T05:30:00Z</dtStart>
> <location>4093 Lankershim Blvd., North Hollywood, 91602,
> US</location>
> </vevent>
>
> </activity:object>
>
I like this general approach but I think it would be better to lose the
"vevent" element and just put the child elements as direct children of
activity:object.
This also allows vevent:uid to be removed, since it's redundant with
atom:id.
Of course, the disadvantage would be that implementations couldn't use a
hypothetical xcal library to parse the content of that element, but to
be honest I'm skeptical that they would anyway.
Either way, it'd be good if you or someone else could work on a short
specification (in a similar approach to my AtomMedia draft) for how the
elements from the xcal schema are to be used in Atom; ActivitySchema can
then reference that specification and/or base its representation of
events on it.
This specification might be called something like "Atom Event
Extensions", or AtomEvent for short. Though I'm a little concerned that
folks might think more of events in the software sense of the term
rather than in the social networking sense of the term; not sure if
there's really a better name, though.
Rob Dolin
There are a number of Social Events services out in the wild including Evite and Upcoming; and MySpace, Facebook, and Windows Live (http://events.live.com/) all have social events functionality.
I'd also suggest considering the verbs associated with a social event. For Windows Live, we originally brainstormed the following actions that would trigger a publish of a new "What's New" activity:
a) Event create/hosting
b) RSVP Yes/Accept to upcoming event
c) RSVP Maybe/Tentative to upcoming event
d) RSVP No/Decline to upcoming event
e) RSVP Yes/Accept to past event
f) Update key details (date, time, location) of event
( We ended-up focusing on b) "is planning to attend", c) "might attend", e) "attended", and f) "updated details for" )
I'm curious if folks think we need new verbs for event-related activities (ex: http://activitystrea.ms/schema/1.0/rsvp-yes/ ) or if folks think we should map events-relate activities to existing verbs:
a) Event create/hosting --> http://activitystrea.ms/schema/1.0/post/
b) RSVP Yes --> http://activitystrea.ms/schema/1.0/join/
c) RSVP Maybe --> ???
d) RSVP No --> http://activitystrea.ms/schema/1.0/leave/
e) RSVP Yes to past --> http://activitystrea.ms/schema/1.0/join/ + check <dtStart>
f) Update --> ??? (do we generally need an update verb?)
Thanks--
--Rob
P.S. It was great to meet many of you face-to-face at lunch at Chevy's.
narp...@gmail.com
seems like there should be an action that is super simple and not
restricted to "attending" per se.
Narendra added EVENT to his calendar.
Narendra updated details for EVENT.
Yvonne French (Yahoo)
Events:
- created
- is going to
- is interested in
- commented on
- uploaded a photo
On Apr 6, 6:55 am, Rob Dolin <robdo...@microsoft.com> wrote:
> +1 on the suggestion for an Event Object Type.
>
> There are a number of Social Events services out in the wild including Evite and Upcoming; and MySpace, Facebook, and Windows Live (http://events.live.com/) all have social events functionality.
>
> I'd also suggest considering the verbs associated with a social event. For Windows Live, we originally brainstormed the following actions that would trigger a publish of a new "What's New" activity:
> a) Event create/hosting
> b) RSVP Yes/Accept to upcoming event
> c) RSVP Maybe/Tentative to upcoming event
> d) RSVP No/Decline to upcoming event
> e) RSVP Yes/Accept to past event
> f) Update key details (date, time, location) of event
>
> ( We ended-up focusing on b) "is planning to attend", c) "might attend", e) "attended", and f) "updated details for" )
>
> b) RSVP Yes -->http://activitystrea.ms/schema/1.0/join/
> c) RSVP Maybe --> ???
> d) RSVP No -->http://activitystrea.ms/schema/1.0/leave/
>
> - Show quoted text -
Martin Atkins
> For Yahoo/Upcoming, we have defined the following activity types for
> Events:
As a side note, I notice that upcoming is using the xcal elements as
direct children of the entries rather than wrapped in xcal:vevent.
Monica, this is probably an interesting datapoint to include in the
events research.
> - created
This would probably just be the "post" verb with the current activity
schema.
> - is going to
> - is interested in
These verbs are unusual in that they don't talk about an action a user
took on a site. Unless there's a good reason not to, I think we should
stick to modelling verbs that describe the action the user made on the
site rather than verbs that describe implied activities. For example, we
don't say that a user took a photo, we say that a user posted a photo.
Likewise, I'd prever to say that the user "RSVPed" an event (better verb
suggestion welcome) rather than that the user "is going to" an event.
For one thing, "is going to" is also odd in that it's future tense,
while activity entries generally describe things that happened in the past.
Of course, the UI layer might choose to call it "is going to" and "might
be going to" or "is interested in".
> - commented on
ActivitySchema currently specs comments as just being objects with
in-reply-to set, so we can already represent this one.
> - uploaded a photo
So an event is also a photo album?
I guess this can be modelled the same way as we model putting photos in
a photo album, but we have a separate thread for that so I won't talk
about it more here.
Monica Keller
http://upcoming.yahoo.com/syndicate/v2/place/kgJTWUqbBZgn5_oU
I can see indeed the vevent is missing. Semantically having the vevent
entry inside the activity object is a bit redundant so I can see
removing this and stating that activity:object with object-type=Event
is the same vevent.
I also see Yahoo is using adr and it works out nicely. I think we
could adopt representing places like this as well, thus helping us tie
the review of a place/venue to events happening there ...
<xCal:summary>Riverboat Gamblers, Miss Derringer</xCal:summary>
<xCal:dtstart>2009-05-29T21:00:00Z</xCal:dtstart>
<xCal:dtend />
<xCal:location>http://upcoming.yahoo.com/venue/8/</xCal:location>
<xCal:x-calconnect-venue>
<xCal:x-calconnect-venue-id>http://upcoming.yahoo.com/venue/8/</
xCal:x-calconnect-venue-id>
<xCal:adr>
<xCal:x-calconnect-venue-name>Spaceland</xCal:x-calconnect-venue-
name>
<xCal:x-calconnect-street>1717 Silver Lake Blvd.</xCal:x-calconnect-
street>
<xCal:x-calconnect-city>Los Angeles</xCal:x-calconnect-city>
<xCal:x-calconnect-region>California</xCal:x-calconnect-region>
<xCal:x-calconnect-postalcode>90026</xCal:x-calconnect-postalcode>
<xCal:x-calconnect-country>United States</xCal:x-calconnect-
country>
</xCal:adr>
<xCal:url type="Venue Website">http://upcoming.yahoo.com/venue/8/</
xCal:url>
<xCal:x-calconnect-tel />
</xCal:x-calconnect-venue>
For the photo being added to an event, does Yahoo use the same UI/
sematics for
-photos being uploaded prior to the event
-photos of the event as its ocurring of after it ocurrred
In the latter case I would opt for the tagging of the event in the
photo concept.
In the attending vs rsvping case. I still see value in conveying that
the response was affirmative or negative throught the verb because it
provides more value to the aggregators for filtering and grouping.
Otherwise we need a new property.
How about: Join/Accept, Consider, Decline potentially Leave
and we definitely need Update as a verb (we can discuss on a separate
thread but yeah this is way common in the wild)
thoughts?
Martin Atkins
>
> In the attending vs rsvping case. I still see value in conveying that
> the response was affirmative or negative throught the verb because it
> provides more value to the aggregators for filtering and grouping.
> Otherwise we need a new property.
> How about: Join/Accept, Consider, Decline potentially Leave
> and we definitely need Update as a verb (we can discuss on a separate
> thread but yeah this is way common in the wild)
>
Agreed that the verb should indicate what the "RSVP" is; I was trying to
suggest that we should model the RSVP rather than the actual attendance
of the event, not that we should just model it all as a single "RSVP" verb.
Using the "join" verb from groups might work. However, that doesn't look
so great when you need to think of a verb to model a "possible" RSVP,
since there's no concept of a "possible" join.
I wonder if we can find a verb for "possible join" that is orthogonal to
type. If we can't then no worries, but it's always better to keep the
verbs orthogonal wherever possible in order to reduce their number.
Monica Keller
type.
http://en.wikipedia.org/wiki/English_modal_auxiliary_verb
So planning to attend could be
<activity:verb>http://activitystrea.ms/schema/1.0/Attend</
activity:verb>
<activity:modalVerb>http://activitystrea.ms/schema/1.0/WishesTo</
activity:modalVerb>
Attend should be a specialization of "Join" and Wishes To an
specialization of modal verb "Will" or we can continue to use Join
Also this will help us in other circumstances, like adding an item to
a wish list could be modeled as
<activity:verb>http://activitystrea.ms/schema/1.0/Own</activity:verb>
<activity:modalVerb>http://activitystrea.ms/schema/1.0/WishesTo</
activity:modalVerb>
Snippet from wikipedia:
>>In the English language, a modal verb is an auxiliary verb that can be used to change the grammatical mood of a sentence. The key way to identify a modal verb is by its defectiveness (they have neither participles nor infinitives).
The modal verbs in English are as follows, paired as present and
preterite forms (where applicable):
shall and should
will and would
may and might
can and could
must (no preterite form)
Let me know
thanks
Martin Atkins
>>> I wonder if we can find a verb for "possible join" that is orthogonal to
> type.
>
> How about we add support for an optional modal verb
> http://en.wikipedia.org/wiki/English_modal_auxiliary_verb
>
> So planning to attend could be
>
> <activity:verb>http://activitystrea.ms/schema/1.0/Attend</
> activity:verb>
> <activity:modalVerb>http://activitystrea.ms/schema/1.0/WishesTo</
> activity:modalVerb>
>
This is an interesting approach.
I agree that this makes grammatical sense, though as usual I'm wary of
adding another axis to activities, further worsening the combinatorial
explosion. Consumers that wish to render activities in natural language
would then need to support (verbs * model verbs * object types * target
types) distinct activity sentences.
Also, this is another example where we violate the current convention
that activities only model things that have happened (past tense), on a
website. What the user did on a website was to RSVP with the status "I
would like to attend", which *implies* that the user would like to
attend the event, but that is not the activity we want to model here.
(At least, as long as we stick to modelling actual social web activities
rather than real-world social activities, but I think we should stick to
that for now until there is some technology for actually tracking user
actions -- assuming makes an ass out of u and me, as they say.)
Monica Keller
I think having an object type Event Invitation or even just object
type "Invitation" and targetting the Event would work well.
$actor is hosting $eventName on $eventDate (verb = post, objecttype =
invitation, target object = event)
$actor is attending $eventName on $eventDate (verb = accept, object
type = invitation, target object = event)
$actor is not attending $eventName on $eventDate (verb = decline,
object type = invitation, target object = event) -- Not sure this
would go on feed but listing for completeness
$actor updated details on $event (verb=update, objecttype =
invitation, target object = event) -- we need the verb update btw
$actor uploaded 5 photos to $event (verb=post, objecttype=photo,
target object = event)
Definition for Invitation would be similar to bookmark and could
include details like # of guests, whether you need to rsvp, etc
Thoughts ?
Martin Atkins
This is an interesting approach. Your first sentence confused me a
little since I guess that sentence should really be "$actor invited
<guest list?> to $eventName...", or "$actor posted an event invitation",
not "$actor is hosting $eventName".
Of course, we'll need to figure out how to model the event guests as you
say.
My only remaining question is what this looks like in the case of an
open event where people can join without being expressly invited. How
can you accept an invitation if you were never invited? Or do we model
that as a public invitation?
I'm wondering whether we need the event object type for this use-case at
all, or whether we can just put the event information in the invitation.
This would seem to be consistent with what an invitation is in the real
world, and for social networking use-cases this seems to hit all the
requirements.
The question is whether there are any use-cases for which an "event" is
appropriate but an "invitation" is not. I'm wondering whether,
conceptually speaking, we can always model an event as being an
invitation from its organizer. One niggle is that it becomes impossible
to post an event without actually inviting the reader to it, which seems
a little strange.
Monica Keller
are :
- Posting pictures about the event (Chris showed us a while back how
facebook and flickr where doing with machines tags) during/after
attendance
- Rating the event after it has ocurred saying whether you liked it or
not. Like concerts and such.
About the who is invited dilemma. I think this is a privacy issue
which can be extended to other activities.
The default should be that if an activity is being surfaced on an
activity stream you have access to, then you are welcome to interact
with it.
Aka if you see the event invite on an activity stream you can rsvp.
Not all activity streams are public of course so the provider of the
feed would have to filter out which ones work in what scenario. Its
the same for photos/blogs for us
Other details we could add:
Whether an RSVP is needed, how many people you can bring and maybe
cost of the events/where to buy tickets.
But this is just an activity so we dont have to put all the details.
The link to the invite should have the rest of the info.
Thoughts?