Re: Finding user profiles on a Social Net

On 6 June 2013 17:01, Goix Laurent Walter <
laurentwalter.goix@telecomitalia.it> wrote:

>  ** **
>
> ** **
>
> *Da:* Evan Prodromou [mailto:evan@e14n.com]
> *Inviato:* giovedì 6 giugno 2013 15.47
> *A:* public-fedsocweb@w3.org
> *Oggetto:* Re: Finding user profiles on a Social Net****
>
> ** **
>
> I think the "self" link relationship works well here, especially with a
> "type" saying what type of data is available.
>
> That can be discovered either in a profile page, a Webfinger account, an
> activitystrea.ms object, or other places that links are discoverable.
>
> -Evan****
>
> ** **
>
> +1. Discovery is essential in allowing to get a direct pointer to the user
> profile endpoint via various means. Then as evan says the type(s) could
> point to a foaf description, poco, etc****
>
> ** **
>
> I would avoid going too much in the direction of adding too many
> well-knowns endpoints for these “rigid” motivations you mentioned…I guess
> we have plenty of entry points / occasions for retrieving the direct
> endpoint in the first place…****
>
> ** **
>
> I’d relaunch the discussion into “searching user profiles” across social
> nets. I guess many opportunities/technologies exist now to start addressing
> this eventually in distributed way.****
>
> Is it utopic?
>

This is a very good point.

In essence there's 3 conversations:

1. "Follow your nose" on links to discover more information from an
existing record.  This is covered quite well in linked data style
solutions, activity streams, link headers etc.

2. Search user profiles social domains.  This is largely unexplored
territory and people are used to finding their friends on facebook using
<firstname> <lastname> with autocomplete widgets.  There's no analog in the
FSW ... largely because of two things 2.1 Forward search is the norm rather
than reverse search, 2.2 Profiles are distributed across domains.  Both
issues are problems waiting for a solution, and can build on existing
profile stores, but as you say, perhaps something for another thread, or
another time.

3. Well known locations as a convenient heuristic to make life a little
easier.  To an extent webfinger is trying to cover this, but it is not yet
standardized, not does it yet return 5 star linked data yet, to my
knowledge, so there may be interoperability concerns.  Nor does webfinger
have a query search language, so reverse search would be infeasible, at
this time.  The solution I propose would address these issues, and also
allows interoperability with existing pattens such as linked data, activity
streams, schema.org, facebook open graph, in a way that would allow apps to
mash things up, and perhaps may pave the way for search as described in (2).



> ****
>
>
>
> On 13-06-06 10:22 AM, Melvin Carvalho wrote:****
>
>     I was thinking about the issue of finding user profiles on a social
> net, and it's not always easy to know where a user's data will be located.
> There seems to be no well known place to get user information from a
> profile.  Which means it's harder for HTTP based social web users to talk
> to each other.****
>
> One increasingly popular method is to use the /.well-known/ directory.
> The disadvantage of this approach is that is it pretty rigid and people say
> it amounts out of band hard coding.  However one advantage is that it can
> save a round trip, compared with follow your nose, and it can client
> implementations more straight forward.****
>
> Taking the well known directory a logical pattern might be to register:***
> *
>
> */.well-known/user/bob*****
>
> For the FSW?
>
> ****
>
> *Would it allow redirects* -- I would say yes.****
>
> *What would it return* -- I would suggest linked data.  Ideally a browser
> would see html and an ajax request would see JSON, but you could start with
> just one of the two, say JSON only.
>
> ****
>
> Good idea / bad idea / too hard to implement ... thoughts?****
>
> ** **
>    Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> *This e-mail and any attachments** is **confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.*
> *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa
> mail se non è necessario.*
>
>