Focussing on implementations and users [was Re: Use cases]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While I think sometimes the use-case discussion can be useful, the
Social XG spent a lot of time with an open-ended collection of
use-cases [1] as pointed out by EvanP. I suggest that the effort to
think up and categorize use-cases in the abstract be continued on the
Social IG, and not the Social Web WG.

The problem in a nutshell is that open-ended use-cases thought up in
the abstract by programmers in a "standards-by-committee" approach in
general does not work historically as it may be produce imaginary
problems and often has little to no relationship to running code.

What seems to work better is focussing on implementations and users.
In particular, we should categorize existing Social Web software and
how they do or do not federate, with a particular look at what they do
now and how many users they already have. Once we have a list of good
implementations with real-world users and can see what problems the
actual users have, we can deduce (similar to the "lean UX" approach)
what facets of our social syntax can solve their problems.

Since quite a few folks in the Working Group have running code with
users and some companies have products in this space (IBM Connections,
SAP Jam), I'd like to see a wiki-page categorizing existing
implementations with estimates on the number of users.

  cheers,
    harry

[1]
http://www.w3.org/2005/Incubator/socialweb/wiki/RequirementsAndUseCases-WorkArea

On 09/21/2014 10:21 PM, ☮ elf Pavlik ☮ wrote:
> On 09/21/2014 08:31 PM, Evan Prodromou wrote:
>> On 14-09-21 12:29 PM, ☮ elf Pavlik ☮ wrote:
>>> On 09/21/2014 05:21 PM, Evan Prodromou wrote:
>>>> On 14-09-20 01:30 PM, ☮ elf Pavlik ☮ wrote: We have a lot of
>>>> use cases listed here:
>>>> 
>>>> https://www.w3.org/wiki/Socialwg/Use_cases
>>> "Friending: As a user on a social network, I would like to add
>>> other social network users to my friends list, and vice versa,
>>> as a basis for further interaction."
>>> 
>>> maybe we could fiddle with that all together? :)
>>> 
>> This would be one of the cases I thought didn't apply well to
>> the document format task.
>> 
>> Even so, let's give it a try. The JSON document could be a
>> payload to an API -- like our upcoming client API -- that
>> communicates your request. So:
>> 
>> * The document format should be able to represent a concept like
>> "Elf wants to add Evan to his friends list." * The document
>> format should be able to represent a person "Elf" and "Evan". *
>> You specify a "friends list", so maybe the JSON document format 
>> should be able to represent that list -- maybe as a collection
>> of people. * The format will be applicable an on-line REST API -
>> so, familiar to client API users, somewhat terse.
>> 
>> Do you see other requirements for our JSON-based document format
>> that come out of this use case? In particular, do you see
>> requirements that aren't already listed in our requirements
>> list?
> As you may see in the syntax vs. vocab thread many people in a
> group may agree that we can express those concepts using certain
> vocabularies and generic and *already standardized* JSON-LD
> serialization of RDF http://www.w3.org/TR/json-ld/
> 
> When it comes to vocabs, I would propose (once again) looking at
> already existing and gaining rapid adoption Schema.org *
> http://schema.org/Person * http://schema.org/FollowAction *
> http://schema.org/follows * http://schema.org/BefriendAction *
> http://schema.org/knows * http://schema.org/potentialAction *
> http://schema.org/AddAction * http://schema.org/collection <-- IMO
> needs much more work!
> 
> In terms of *friends list* I start exploring various ways of
> approaching collections:
> https://www.w3.org/wiki/Socialwg/Collection_Comparison
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUH1aUAAoJEPgwUoSfMzqcqOoP/2V2zhc+Zmq2OAEtT/9t0BhZ
0+198KXQez80TdQJDQk5DdCTRL2C5AYA2ywqfolQCz96UddLciW8BX3LiScRutph
Hv3+sBQgRiEzueGHgQJod+Sk66e2JhHXBuO/hiKtfB41e7z5P2UZYjvjJnACH37S
u2dT+grEl6q19brY6CM0cDUJMaID2YEv6JRLA8U9UmC6qCP73GS7e3uAira5uNA8
G7myVzy3T/NKvE4Li5NWSNMQweJynCM9yOnpTt0P84xa0P/ycC7uPk1WQGxL6uf+
UNdArfA0Qq06/P2+AuhoDRoIeQTfU8Kzgf9YuAVBpr9vAtiN3+M+ci4AHLucTikp
wjzIl2XE063H8hJepMai+zIefDCjzCqWyKTwxcJKqp5Qy1i1JVqwVTeYnyADqPRK
1tNkBiW9SvMldVxOtiGS0NlSN/6hrYNLvdbmuuMvVMReKJ6UqIyAttjwryAucA35
MOtDun/RG86lUPxwmxEwiuaqoBRRiglYFZhzCqA0C02IjqhoHYIbNbX7D0Gig+uA
nu75f9KPnaivu5ZTfSL3YDmRzityTwwPxI8VdtiABQDQ3kDMaFvqa+qzbwutRTNk
FwTBsWWfN3i7jikSPBwa3Y4jCkTi2xFQAD/m/apdeIUv8m+nUyhYurItxuSmLzbr
KCTmS/k2/fg3BdUwbPQF
=J0Y8
-----END PGP SIGNATURE-----

Received on Sunday, 21 September 2014 22:52:13 UTC