Re: a common understanding of profiles

On 26 June 2015 at 03:57, Evan Prodromou <evan@e14n.com> wrote:

>  On 2015-06-24 07:16 AM, Melvin Carvalho wrote:
>
>       So, I was wondering if it could be possible to try to come to a
> common understanding of profiles.
>
> A "profile" should be a retrievable resource with some representation of
> an "actor" in our system -- a node in a social network, preferably one that
> authors (=creates) content and can make connections to other actors.
> Usually a real person, but sometimes a fictional person, or a company, or a
> product, or a physical object, or a software process.
>
> Since we're standardizing on AS 2.0 as our social syntax, and since our
> Social API and Federation protocol are supposed to use that social syntax,
> a "profile" should be a resource represented by a AS 2.0 actor object --
> usually a Person.
>
> So when you GET https://evanprodromou.example/profile the response would
> be something like:
>
> {
>   "@context": "http://www.w3.org/ns/activitystreams" <http://www.w3.org/ns/activitystreams>,
>   "@type": "Person",
>   "@id": "https://evanprodromou.example/",
>   "displayName": "Evan Prodromou",
>   "alias": "eprodrom",
>   "summary": "Founder of Fuzzy.io. Past founder of Wikitravel and StatusNet. Founding CTO of Breather.",  "icon": {
>     "@type": "Image",
>     "url": "https://evanprodromou.example/avatar.png",
>     "width": 128,
>     "height": 128
>   },
>   "url": {
>       "@type": "Link",
>       "href": "https://evanprodromou.example/" <https://evanprodromou.example/>,
>       "mediaType": "text/html"
>   },  "location": {
>        "@type": "Place",
>        "displayName": "Montreal, Quebec, Canada"
>   }
> }
>
>
Thanks for posting an example.

In SoLiD we dont yet have complete support for JSON LD (we tend to use
turtle), but making a change to produce and consume JSON LD, I think is
something we'd like to do, and is being worked on.  I would expect that to
happen during the lifetime of this WG (probably before we go to CR).  That
would enabling testing of profiles such as above.  For example, currently
my own profile doesnt support JSON LD, but if there's going to be interop
advantages in the future, I would invest time in making that happen.

I wonder would indieweb also be prepared to do the same?

Regarding the URI above.  It can become slightly problematic attaching key
value pairs to an HTTP document, also doubling as a Person.  Some things
dont make sense e.g. if a document has a creative commons license, an etag,
and various other HTTP headers or meta tags, they automatically get
attached to the person too.  Other things can become ambiguous, e.g. if a
document has a title (Evan's Profile), and a person has a title (Mr.) it
can be ambiguous.  The example I brought up previously was a "like".  I
might like Ricky Martin's homepage, but might not like Ricky Martin.  This
list goes on.  From my experience of implementation the area that this
tends to fall down is with caching strategies, when software may become
confused with fetching documents and the data inside those documents.  In
general, this is a confusing part specific to HTTP when key value pairs are
attached -- we tend not to attach key value pairs to filenames or database
tables, but it's more common on HTTP -- my guess is that this is because
HTTP URIs are overloaded as both pointers/names and dereferencable
identifiers.  In any case, for this reason, many of us using solid tend to
have a URL as profile, and then the Person inside as a # URI relative to
that.

So, how to get interoperable profiles?  The pattern that is probably best
practice comes from openlink.  They have automatic translators from a base
page (lets take a github profile) to linked data :

http://linkeddata.uriburner.com/about/html/https/github.com/melvincarvalho

in this pattern the owl : sameAs relation is used and the #this keyword is
added (much like 'this' in javascript refers to 'this' object).

I think this kind of glue would work to bridge two such profiles together
into an interoperable and browsable social graph.  I'd love to hear ideas
on this, especially from those with implementation experience.  Because it
would be nice to also test this with real world examples.

If there's enough interest too, perhaps this is something that could also
be standardized in the WG, the IG or another W3C group.

 Figuring out where to look for "Evan Prodromou's profile" is an important
> part of the Social API.
>
> -Evan
>
>