- DRAFT -

Social Web Working Group Teleconference

24 Feb 2015

Attendees

Present: bblfish, Arnaud, aaronpk, +1.617.247.aaaa, ben_thatmustbeme, tantek, +1.857.445.aabb, eprodrom, harry, bret, +1.408.335.aacc, rhiaro, KevinMarks, bill-looby, Ann, Sandro, Tsyesika, wilkie, cwebber2
Regrets Chair: tantek
Scribe: aaronpk

tantek: i don't expect us to use all the user stories to develop the api, but that being said, since each user story seems to be useful to multiple people, i think that means they are worty of continued iteration
... if not in the first version then in additional versions or extnesions
... this is all valuable input we're getting
... just because stories have a bunch of -1 it doesn't mean we're going to throw it out and never lookat it again

AnnB: i totally agree, want to point out that in the case of the more "unusual" "obscure" stories,
... often innovation happens at the edges

<Loqi> Cwebber2 made 1 edit to Socialwg/Social API/User stories https://www.w3.org/wiki/index.php?diff=82359&oldid=82358

AnnB: that's where different and unusual ideas occur

<KevinMarks> if downvoting is seen as hostile we cut our range in half for +1 to -1 downt o +1 to 0

<rhiaro> I think a lot of the more 'unusual' ones can be generalised, too, and are accommodated anyway

AnnB: i'm looking forward to the discussion on the more unusual suggestions

tantek: since we have agreement on postponing the process of turning the stories into requiremetnts we've reached the end of the ageda
... everyone is eager to get back to voting i'm guessing

<cwebber2> \o/

<harry> keep voting everyone!!

tantek: if there are no objections, would move to close the call and give back the remainder of the hour to continue voting!

Arnaud: one possiblity would be to pick up some user stories that are popular but are some objections, and maybe we can clarify some of them now

tantek: okay that's reasonable

AnnB: do you have ones you want to highlight?

Arnaud: there were some with major numbers of +1 and then a -1 from tantek
... the very first one, user profile management

<tantek> https://www.w3.org/wiki/Socialwg/Social_API/User_stories#User_profile_management

<ben_thatmustbeme> +1 i would like to be able to iterate on some of these stories or propose alternate versions

tantek: in having lookde at this, I agreed with most of the user story, but some of the fields used for profile management seemed to be very specific and not necessarily needed or present in the APIs we reviewed
... i agree with the general theme but had some specifics i was objecting to
... perhaps evan can clarify?

<bill-looby> have to drop, bfn

<rhiaro> My reading of that was that the specific profile data is arbitrary, and those given are just examples

<AnnB> me too, rhiaro

eprodrom: hometown - it gets down to what you think the location field on twitter is for
... it's kind of up in the air. facebook has a way to say this is where i'm from or this is where i live
... job title and company name we have in linked in
... those are pretty common
... job title is pretty common in enterprise networks
... phone number is in facebook and linkedin, most enterprise networks
... i've also seen some systems where you can update private data
... as far as the specifics, i think that would be up to how the profile works and up to the individual APIs we get proposals for
... whether they use a fixed vocab for the profile or changed by the implementation
... but the idea that we are able to be able to update multiple parts of the profile is important

<rhiaro> +1 updating multiple elements of profile, but not requiring specific fields

tantek: that makes more sense to me especially the last thing you said, updating parts or mnultiple aspects of the profile
... that I agree with in a +1 way
... but that feels like some of the aspects may be getting into profile vocab design which i would like to avoid
... would rather reuse all notion of profile vocab from an existing standard like vcard 4
... and looked at existing networks while that was developed
... i would +1 the profile management if it mentioned that the fields are used as examples and it's up to the service what field it supports

eprodrom: i think we can get into some interesting fine points
... for example if you have a client that tries to update fields that aren't on the server
... if the client doesn't understand the profile response from the server how should it handle it
... those are good discussions to have around the user stories

<tantek> ack?

bblfish: this shows a little of a confusion between the API and the data format

<bblfish> http://www.w3.org/2000/10/swap/pim/contact#

bblfish: because if you take the data format carefully like JSON LD then it's extensible

<KevinMarks> look at existing profiles for intersection, rather than union

<bblfish> http://www.w3.org/People/Berners-Lee/card

bblfish: you could use the contact ontology like timbl does for his profile, but it doesn't have to be part of this WG to describe all the ontologies

<KevinMarks> opensocial went for union, which meant we ended up with too many fields

bblfish: so i read it that there is no requirement for the WG to specify the ontology, just that the API be able to edit the information as needed
... i've seen this type of example where people get caught up on the API vs the schema

AnnB: i think this was largely resolved so far but hasd one concern
... "well twitter and instagram don't have it so it's unnecessary" seems like a narrow perspective
... doesn't necessarily mean that the whole world doesn't need it, especially in enterprise it varies significantly

tantek: if something is not ever-present then it's probably not core. it's okay to consider more complex cases, i'm focused on getting out a v1 of the api
... the extensibility henry described is the kindof thinking i'm hoping goes into the api byt didn't want to assume that

<rhiaro> +1 for not defining everything, and helping servers have decent fallbacks instead when they don't understand things

tantek: i asked for clarification from evan about whether this is specifying specific fields or leaving things a bit more open
... and then define rules for publishers and consumers handling support for different fields
... evan is that a reasonable summary?

eprodrom: i think it is up for discussion

<bblfish> +1 for tantek's description of the two approaches - I am for having an API that can work with any data ( though the working group could decide on a minimal yet extensible ontology that all clients should understand )

eprodrom: my feeling is that we want to use some vocabulary in there, i'd probably wnat to use a well-known vocab here to make things easier for implementers

AnnB: this seems like a valuable discussion, it's foundational to how this goes forward

tantek: to be clear my +0 is not an opposition

harry: we do have a requirement that we will use the IG input as a building point
... regardless of how big the union/intersection of terms in the API becomes, i would be shocked if we did not have some extensibility mechanism

<rhiaro> +1 extensibility

AnnB: that's a good point about the IG but i will need to understand that better

harry: as soon as we get a v1 of teh API that peopel agree on, people will notice "it doesn't quite fit my use case" do we need to create another vocab or format and can send it to teh IG to continue working on

tantek: i strongly agree with intersection instead of union

<cwebber2> phone died, sorry

<bblfish> as long as things are extensible.

AnnB: since i'm not a developer, i'm having a hard time assessing what goes into the API instead of UI or some other mechanism
... you who are developers can guide me that way
... it's too bad Adam got pulled out this week, since he's my local developer 'explainer'

?? that discussion of what goes into an API vs UI could go on for hours

scribe: i certainly encourage people to discuss that in IRC but not sure it's worth taking time in the telcon

<AnnB> agree .. just pointing out this is a aspect of confusion for me

<bblfish> https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Developing_a_Smart_client

<AnnB> s/a aspect / an aspect /

bblfish: what it's trying to say is most of what's published is data, and the client uses the data to create the user interface
... and then the API is how you change the data, how you create new data, that's my way of seeing the three layers

<AnnB> thanks Henry

bblfish: API, data and user interface

tantek: okay
... anyone else want to bring up any questions?

<tantek> https://www.w3.org/wiki/Socialwg/Social_API/User_stories#User_posts_a_note_with_embedded_media

tantek: use posts a note with embedded media
... there is a challenge ... it's not clear whether video embedding is done simply via a URL or where it's something where you upload a video
... based on the two interpretations i have completely opposite votes
... simply pasting a URL, having auto-embedding is a pretty common feature, i've even implemented it on my site

<rhiaro> In my experience video uploading comes with a ton of extra baggage, or at least tends to require additional metadata

tantek: but a -1 for making video uploads a core part of the api

<cwebber2> really?

tantek: so are jessica or christopher here to clarify the intent?

<bret> rhiaro: ever had to maintain a dedicated ffmpeg server ;)

<harry> ?

<cwebber2> hold on

<cwebber2> I dropped off the call but I have to reconnect

<cwebber2> +q

<Loqi> Kmarks2 made 1 edit to Socialwg/Social API/User stories https://www.w3.org/wiki/index.php?diff=82362&oldid=82359

eprodrom: first, this becomes a more mainstream user story if it's an image used in a text, so the flow of posting an image and putting it int he text and sharing that
... the other thing is sounds like your -1 for video, but a lot of the folks from mediagoblin are here and doing sharing media
... audio and video and images

<Tsyesika> I'm here but i don't have a mic so i'll let chris take this

cwebber2: i think that media upload, wit's not true that the service should be required to handle large media upload, but the api should be designed so that we know how this would work
... it would be surprising to me if we don't have a way to define here is how we handle large uploads

<rhiaro> Would be good if you could upload your video to one server and embed it in a post on a different server simultaneously... Seems like something the API could help with

cwebber2: it's okay if services say it's not possible to handle certain formats

tantek: the reason i was not sure about this was that this story specifically mentioned someone else's video
... so samantha is writing a post and embeds helen's video, my optimistic interpretation was that samantha puts in a URL to the video

<wilkie> is there an ability to replicate media for reposting?

tantek: but then I realized perhaps this was meant ot cover video uploading
... i agree it would be good to have a user story on video uploading, but this seems more like sharing a link to something online

cwebber2: that user story we submitted was about sharing a link to something already online
... i thought that other user stories had already covered video uploading
... it looked like there was a question about whether video uploading should be able to happen at all
... i do think that submitting video, even though that's not hte user sotry in question, is important. sorry if there was confusion, my phone screwed up

tantek: so the "user posts a note with embedded media" is about sharing existing video already online

cwebber2: exactly

<rhiaro> Note: Vine is a social network based entirely on sharing video, so definitely required for social..

tantek: okay that clarifies that one

<tantek> https://www.w3.org/wiki/Socialwg/Social_API/User_stories#User_posts_a_note_with_embedded_media

<tantek> https://www.w3.org/wiki/Socialwg/Social_API/User_stories#User_posts_a_file

<Arnaud> someone needs to clarify the story so this is no longer ambiguous

ben_thatmustbeme: should we use the "more stories" page to try to clarify these?
... should we be constantly making new ones to say here is my interpretation of these stories

tantek: i think that's a great idea, it will help us converge on user stories
... the "more users" stories page is...

<tantek> https://www.w3.org/wiki/Socialwg/Social_API/More_user_stories

tantek: there's nothing on there now, but that's a great suggestion
... one way of clarifying a story or clarifying your vote
... you can say "+1 on this assuming..." and link to your interpretation

<eprodrom> Approaching the hour, btw, tantek

<harry> I warned people re the stories :)

AnnB: i think that's a great suggestion but i'm worried that there are so many of these stories that its going to be a nightmare to go back and forth between all the versions

<ben_thatmustbeme> that was my concern at all

AnnB: is there a way we can discuss this more diretly inline?

tantek: people have been doing that already
... ben's proposal was an additional option to people

AnnB: i'm totally supporting the concept of further discussion, just worried that if we birfurcate this then how we're going to track it

tantek: hopefully with links

AnnB: links are great but they can also be confusing

tantek: we're approaching the top of the hour
... there's no end to discussing the details of these stories
... for the "posts a file" did you mean photo only or any kind of media file or any kind of file?

https://www.w3.org/wiki/Socialwg/Social_API/User_stories#User_posts_a_file

eprodrom: from the original requirements, we had images,text,video,audio,enterprise docs and other types
... so that user story was supposed to summarize those groups
... we could break it down to multiple groups

<Loqi> Rhiaro made 1 edit to Socialwg/Social API/User stories https://www.w3.org/wiki/index.php?diff=82363&oldid=82362

<Loqi> Eprodrom made 1 edit to Socialwg/Social API/User stories https://www.w3.org/wiki/index.php?diff=82364&oldid=82363

eprodrom: I was trying to take from the original user requirements around 10 high-level areas, one for each

<AnnB> s/diretly /directly /

eprodrom: so that "upload a file" became "upload an image"
... as far as cropping, the idea was the user was cropping is they'd use their own software like photoshop, not part of the API

tantek: that's a good example of a reasonable clarification to add as bullet points as part of the description of the story

<AnnB> +1 ... I like the small clarifications people have added .. it's helpful when they are indented

tantek: if you want to put a brief bullet list clarifying "crop is not intended to be part of the API" that's totally reasonable
... i'd rather optimistically trust that people add clarifications to narrow the scope and won't abuse that
... i would encourage folks, if you're seeing questions or objections on your story, you can clarify

eprodrom: that sounds fine
... at this point i'd rather not change the formatting on the stories, we're hours away from finishing. but if people want to add additional bullet points that's great

tantek: any objections?

<rhiaro> +1

resolved: if you're the author of the user story you may add clarifying comments in the voting area

<eprodrom> +1

<harry> +1

tantek: that brings us well past the top of the hour but hopefully that helps us get more consensus on user stories
... thanks again, we'll reconvene next week and figure out our next steps

<rhiaro> ciao!

<wilkie> cool, thanks

<eprodrom> Thanks tantek !

<bblfish> thanks

<bret> cheers

<wilkie> aaronpk++

<Loqi> aaronpk has 714 karma

trackbot, end meeting

Summary of Action Items

[NEW] ACTION: harry to invite Annotations WG [recorded in http://www.w3.org/2015/02/24-social-minutes.html#action01]

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-02-24 19:05:03 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/that'st he/that's the/
Succeeded: s/evna/evan/
Succeeded: s/loking /looking /
Succeeded: s/muliple/multiple/
Succeeded: s/devloped/developed/
Succeeded: s/valuaable/valuable/
FAILED: s/a aspect  / an aspect /
Succeeded: s/pulled out this week/pulled out this week, since he's my local developer 'explainer'/
Succeeded: s/in a post/in a post on a different server/
Succeeded: s/tha'ts a /that's a /
FAILED: s/diretly  /directly  /
Succeeded: s/iwas /I was /
Found ScribeNick: aaronpk
Found Scribe: aaronpk
Inferring ScribeNick: aaronpk
Default Present: bblfish, Arnaud, aaronpk, +1.617.247.aaaa, ben_thatmustbeme, tantek, +1.857.445.aabb, eprodrom, harry, bret, +1.408.335.aacc, rhiaro, KevinMarks, bill-looby, Ann, Sandro, Tsyesika, wilkie, cwebber2
Present: bblfish Arnaud aaronpk +1.617.247.aaaa ben_thatmustbeme tantek +1.857.445.aabb eprodrom harry bret +1.408.335.aacc rhiaro KevinMarks bill-looby Ann Sandro Tsyesika wilkie cwebber2
Agenda: https://www.w3.org/wiki/Socialwg/2015-02-24#Agenda
Found Date: 24 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/24-social-minutes.html
People with action items: harry

[End of scribe.perl diagnostic output]

Socialwg/2015-02-24-minutes

- DRAFT -

Social Web Working Group Teleconference

24 Feb 2015

Attendees

Contents

minutes from last week

next week's telcon

Annotation WG

Social API User Stories

Summary of Action Items

Scribe.perl diagnostic output