Re: reusing Vocabulary terms in Social API (Hypermedia)

On 01/21/2015 09:14 PM, ☮ elf Pavlik ☮ wrote:
> Hello,
> 
> Since we start clarifying our direction in Social API, I would like to
> discuss leveraging *terms* which we find in existing vocabularies and
> new one's which we work on.
> 
> First I will make short detour. In Architecture of the World Wide Web,
> Volume One we find:
> 
>     Good practice: URI opacity
> 
>     Agents making use of URIs SHOULD NOT attempt to infer properties
>     of the referenced resource.
> 
> http://www.w3.org/TR/webarch/#uri-opacity
> 
> In context of our work I would interpret it as:
> "Since URIs should stay opaque, we SHOULD NOT mandate what to include in
> URIs denoting resource in API - no *magic* paths!"
> 
> If someone wants to expose all the resources using URIs like
> 
> * https://example.com/c251a9aa-bf89-466f-a8d5-a18ea5377f70
> * https://example.com/18d96e54-cfb6-4d14-bef0-80addf21e7a2
> * https://example.com/58438e23-fe45-4589-8ecb-43a459da075a
> 
> Everything should still work :)
> 
> 
> How do we find then things like: *list of elf's friends*?
> 
> HYPERMEDIA to the rescue \o/
> 
> Many people feel quite comfortable with *link relations*. When someone
> publishes and article with multiple pages. This person doesn't need to
> follow conventions like: "For second page add /2 to your URL" etc.
> Once we fetch (dereference) given web page, we can simple search for
> links with rel="next" or rel="prev" leaving publisher freedom to use
> whatever they want in their URLs.
> One can find many more such link relations on microformats wiki,
> referenced in official HTML5 spec!
> http://microformats.org/wiki/existing-rel-values
> 
> In similar way everyone could find list of my friends. Once someone
> fetches (dereferences) my online profile, could search in it for links
> with rel="knows" or rel="follows". Actually RDFa reuses rel attribute
> and we can also use similar pattern in JSON-LD or turtle.
> (we can find relation/property/predicate *knows* in FOAF or schema.org!)
> 
> Since I know few thousands of people, and other people find themselves
> followed online even by millions of other people. We need a way to avoid
> publishing all those links directly on our homepage! One of the proposed
> solutions comes from Hydra CG -
> https://www.w3.org/community/hydra/wiki/Collection_Design
> 
> {
>   "@context": {
>     "@vocab": "http://schema.org",
>     "hydra": "http://www.w3.org/ns/hydra/core#"
>   },
>   "@id": "https://wwelves.org/perpetual-tripper",
>   "name": "elf Pavlik",
>   "hydra:collection": [
>     {
>       "@id": "https://wwelves.org/perpetual-tripper/friends",
>       "name": "elf Pavlik's friends",
>       "hydra:manages": {
>         "property": "knows",
>         "subject": "https://wwelves.org/perpetual-tripper/friends"
>       }
>     },
>     {
>       "@id": "https://wwelves.org/perpetual-tripper/events",
>       "name": "elf Pavlik's events",
>       "hydra:manages": {
>         "property": "attendee",
>         "object": "https://wwelves.org/perpetual-tripper/friends"
>       }
>     }
>   ]
> }
> 
> Even that I chose to use vanity URLs ending with /friends or /events, I
> could as well use generic /c251a9aa-bf89-466f-a8d5-a18ea5377f70 and it
> will still work. If you read this example carefully you would notice
> that I even used attendee relation/property/predicate in *inverse*
> direction :)
> 
> I will leave it here and I hope we can discuss together various
> advantages, and possible drawbacks of such approach...

ADVANTAGES++
In many cases one will keep one's photo/video/audio albums on *another
domain* than one's social profile, also powered by dedicated multimedia
backend e.g. MediaGoblin.
We MUST NOT assume that all the social data stays available under / path
of some particular domain which may just host just an Identity/Profile
and no other 'social artifacts', instead delegating it to other data
spaces on the web!

Bill, do you see it relevant to your *Integration* User stories?