- From: <henry.story@bblfish.net>
- Date: Fri, 20 Feb 2015 20:22:58 +0100
- To: Ben <ben@thatmustbe.me>
- Cc: Social Web Working Group <public-socialweb@w3.org>
- Message-Id: <9C3726E5-EC73-4088-BA99-FA4A09E4A877@bblfish.net>
> On 19 Feb 2015, at 17:04, Ben <ben@thatmustbe.me> wrote: > > Hi Henry, > > I'll try to explain these one by one, I didn't want to flood the page with too much discussion of every one. I figured it was more just for voting. Maybe we'll see me get over-ruled by plenty of +1's. > I also fixed in on what was said about wanting to complete a first revision of the API quicker and to cut the excess. Lots of the stories I down-voted was not because they aren't useful but they would add a lot of complexity that can be looked at after we get something working initially. > > > On Thu, Feb 19, 2015 at 10:23 AM, henry.story@bblfish.net <mailto:henry.story@bblfish.net> <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote: > I just picked up a lot of -1 by Ben Roberts, which are not very well defeneded I think. > So it's easier to have the discussion on the mailing list when these things turn up. > > > Product issue reports > ===================== > > • Each product a company makes has its own URL which can be read off the product. From that URL the user can find the history of the product, from creation to the present. > • Only the current buyer and the company has access to that page > • A user finds a problem with his product and goes to his Product page. There he can open a new bug report. > • He can upload pictures of the problem, descriptions, and discuss with the Technical Support Staff > • The Technical Support Staff or the User can add new people to the discussion, eg. technical experts, parts manufacturers, sales people, legal, etc... > • New members can then contribute to the discussion bringing their expertise to bear. > From User:Bblfish > -1. Doesn't really seem like a social network feature to me. Perhaps a company would have a social account that could handle, but getting to product level gets too specific. — Ben Roberts (talk) 02:00, 19 February 2015 (UTC) > > ----- > > Well it is social because people communicate on a topic. Instead of discussing a picture on a wall, you can create > an issue on a product. Additionally you can enlarge the group of people who can see the issue, to include more people in the discussion. > > Does that help? > > > I voted this one a -1 because I don’t see creating URLs for physical items or managing what users have purchased what items as being involved in the social API. A lot of the stories have some background assumption that does not immediately involve the API. Living in a house and having friends is obviously not something that the API is going to solve. This story says nothing about the API being used to creating a URI for a product. …Mind you if the social web allows us to create URIs for text, pictures and videos, then why could it not also create URIs for other things? As it happens that is in fact possible with LDP to create URIs for products. > Anyone hosting their own service could certainly go ahead and add that, and this would be a great user story for a developer of that system, but I don't think its a good User Story for our purposes. I am trying to keep anything that is a custom solution separate from the general social API. What is not social about people from different organisations working together to fix a bug? Clearly the working group may not want to develop a bug ontology to describe bugs, but those parts of the Social Web API that do work, should immediately work for a bug database too. That would show the API was well designed. > > > Using a Smart Client > ==================== > > • Jillian downloads iFoaf to her smart phone, starts the program, enters her identity, and authenticates herself to her home server. The client gets her profile data and initiates the application with data taken from her Social Web Server and her client > • The Application asks Jillian if she wishes to add people found in the smart phone address book to one of her already published groups or a new one. Denise publishes them to a new group, to categorise later > • As Jillian is an EFF advocate she travels a lot, and so do many of the people she is in contact with. So she often does not know what time it is for the person she wants to call. But she has convinced 50% of her friends to have their own home servers with Social Web compliant APIs. > • Jillian uses iFoaf to call people. > • If the person she wishes to call publishes her time zone info, Jillian can know if it is advisable to call them. > • Jillian always gets the latest phone number people are using, and never has out of date phone numbers > • As Jillian travels iFoaf can let her know what friends of hers happen to be in the same town. She can quickly message them to say hello. > • Any messages Jillian sends travels over an encrypted channel directly to her friends computer, so Jillian knows that her messages are never read by anyone else than their intended recipients. > • Jillian's server also allows traffic over Tor, to allow her to communicate with people in politically sensitive positions. > From User:Bblfish. > > -1. Seems more Use case for the app, not the API. — Ben Roberts (talk) 02:00, 19 February 2015 (UTC) > > ------- > > I don't see how you can distinguish in a user story between what the interface gives you and what API that it communicates over gives you. Furthermore this used to be part of the developer section, which was removed, so yes > that is why it is developer focused. Not sure why that deserves a -1 though. > > There is a LOT going on in this story, not that its a bad thing. But upon reading this over again, you are right, i'm not sure it deserves a -1. I was trying to lean more toward excluding excess than including too much. Getting a user's time zone and phone number is important to include, but that is inferred any time you get a user's profile. What you do with it after that is more of the app's territory. That’s what dissuaded me from it. This example is more about how friend of friend networks linked across continents and across organisations can be used by an app to do something useful. Obviously the phone is the one meant to do a bit of geo-location not the API. Thanks for removing the -1. > > > > Follow a neighbourhood group > ============================ > > • Joe, Jane and their children move into a new house and Joe brings his personal server to the new house, and switches it on by plugging it into the wall and connecting it to the fibre optic cable. > • The server sets up the DNS so that all Joe's previous contents are now available at the same URLs as in his previous house, meaning that his social network is back online. > • One of Jane's friends notices their new geo-location over the web and introduces them to Jack, one of Joe's neighbours. > • Jack and Joe accept the friend of a friend (foaf) invitation and Jack comes by the next day to say hello. > • Jack adds the family to the neighbourhood group ( stored somewhere ), and sends Joe a hello message welcoming him to the group. > • Joe receives the hello message the next day, visits the group, and leaves an introductory message for his neighbours. > • On that group Jane discovers that there is a collective barbecue the next weekend and leaves time in the calendar for the family to go there with the family. > • After the barbecue Joe connects up directly with some of the neighbours he ended up in longer conversations with. > • These closer friend relations gives those neighbours more access to each others plans, allowing them for example to organise taking kids to school on a rotary basis. > From: User:Bblfish > -0. Seems like mostly a dupe of #Groups, with lots of plumbing added. --Evan Prodromou (talk) 15:31, 18 February 2015 (UTC) > -1. Too complex — Ben Roberts (talk) 02:00, 19 February 2015 (UTC) > > So it's either too complex, or a duplication with a bit of plumbing of #Groups. > Why is it too complex? > > It seems that at the very least it is stretching the imagination a bit, since what seems like a normal group > participation story now seems to be something super complex to do :-) > > > Too complex of a story. There is a lot going on here, identifying nearby users by geo-location, There is no identification of users here by geo-location. One of Jane’s friends finds out that the family have moved to a new house. ( That’s what you’d find out if you looked at someone’ profile and found that they had changed address ). The application can be clever enough to show her all her friends on a map, and allow her to see that a few friends are suddenly neighbors. > adding others to a group without choice (Jack adds the family to the neighborhood group). How would you want to write a decentralised API that makes that impossible? That is also what following is, btw. Trying to make participating in a group something people have to agree to, is impossibly difficult in a decentralised environment. It is akin to the error the pre-web hypertext people made when they wanted linked to always be verified. Removing that requirement is what made the web the successful platform that it is. > I feel like these are just more complex versions of #Groups. So yes, this user story is a duplicate and made too complex. It is a bit complex, but what it makes clear is how you can move from one place to another, and keep your social network and your data on a physical device you own without loosing your data. That to me is a key requirement for a social web platform. > > Assigning roles during meeting > ============================== > > • Telecon starts > • Ann assigns herself as a chair > • Lloyd assigns himelf as a scribe > see also: https://www.w3.org/wiki/Template:Agenda-preamble <https://www.w3.org/wiki/Template:Agenda-preamble> > From: elf Pavlik > -1. I don't think we need to manage teleconferences with this API. --Evan Prodromou (talk) 15:51, 18 February 2015 (UTC) > -1. Perhaps later, but not for the first version of the API. — Ben Roberts (talk) 05:00, 19 February 2015 (UTC) > > I think what we need to do is distinguish between the API and the vocabulary here. IF the API is general enough > it should be easy to do the above once one has the correct vocabulary. Now in games on social networks, assigning oneself to roles is quite common. So it seems that this is just doing something like that, which is not very complicated. > > Looking this over, this seems like something that would actually be perfectly reasonable in an app, but I don’t > think it makes sense to have every event be able to have a set of positions at the event. You are right. Events that allowed this would be subsets of general events. It would require a particular ontology that the group need not develop. > This is easily completed with just text and the permissions become really complex as to who is allowed to assign themselves to what positions, etc. Yes, the access control part would be a lot more difficult. But luckily the group does not need to consider access control ( other than as being needed ). At the very least this user story brings up an interesting access control requirement. > > Henry > > > Social Web Architect > http://bblfish.net/ <http://bblfish.net/> > > > > Hope that clears up some of my voting on these, would people prefer I give longer discussions on the user stories page? > > Ben > https://ben.thatmustbe.me/ <https://ben.thatmustbe.me/> Social Web Architect http://bblfish.net/
Received on Friday, 20 February 2015 19:23:30 UTC