Re: Fwd: reusing Vocabulary terms in Social API (Hypermedia)

Hi Elf,

I wonder about the subject of the :knows collection. Wouldn't it have to be 
"https://wwelves.org/perpetual-tripper" rather than 
"https://wwelves.org/perpetual-tripper/friends"?

Or do you mean to say the entirety of friends of Elf knows the entirety of 
Elf's friends? At least that is how I read the subject.

Cheers,
Dietrich

On January 21, 2015 9:23:49 PM ☮ elf Pavlik ☮ 
<perpetual-tripper@wwelves.org> wrote:

> I welcome your feedback on my email to Social WG where I try to
> introduce approach based on Hypermedia for Social API :)
>
>
> -------- Forwarded Message --------
> Subject: reusing Vocabulary terms in Social API (Hypermedia)
> Resent-Date: Wed, 21 Jan 2015 20:15:21 +0000
> Resent-From: public-socialweb@w3.org
> Date: Wed, 21 Jan 2015 21:14:57 +0100
> From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
> To: public-socialweb@w3.org
>
> 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...
>
> Cheers :)
>
>
>
>
>

Received on Thursday, 22 January 2015 08:43:20 UTC