W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

Re: remove hydra:Link (branched from remove hydra:Resource and hydra:Class)

From: Tomasz Pluskiewicz <tomasz@t-code.pl>
Date: Mon, 12 Jan 2015 18:57:21 +0100
Message-ID: <54B40B01.10600@t-code.pl>
To: public-hydra@w3.org
John,

I think I see your point here. The general use case is that Link header 
given clients access to the ApiDocumentation. It's general structure is

ApiDocumentation
   SupportedClasses
     SupportedProperties
       Operations.

So what about hydra:Link? Dereferencing is not an option for 3rd party 
vocabularies and I agree with John's reluctance for subclassing. Maybe 
GET operation should always be used instead. Be it inline or declared in 
SupportedProperty's definition?

On 2015-01-12 13:38, John Walker wrote:
>>
>> Fair enough. As far as I'm concerned: to be discussed next :-)
>>
>
> Let's get the ball rolling then.
>
> One downside I see of using the hydra:Link class is that if I want to use
> existing vocabularies that I do not control, then I need to make a sub-property
> of whatever property I want to use and then state that my property is a
> hydra:Link. For example if I want to indicate rdfs:seeAlso is a link in my API
> then my API documentation would include something like the following Turtle:
>
> @prefix : <http://example.com/def#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix hydra: <http://www.w3.org/ns/hydra/core#> .
>
> :seeAlso a hydra:Link ;
>    rdfs:subPropertyOf rdfs:seeAlso ;
>    rdfs:range :SomeDocument ;
>    hydra:supportedOperation [
>      a hydra:Operation ;
>      hydra:method "GET" ;
>      rdfs:label "Fetch the related resource" ;
>      hydra:returns rdf:Resource
>    ] .
>
> In this example I have purposely extended/specialized the definition of
> rdfs:seeAlso specifically for use in my API for sake of discussion, but would
> say that in the ideal world I would somehow be able to use the original property
> URI rdfs:seeAlso rather than having to make a specialized property.
>
> So my API documentation would be something like:
>
> @prefix : <http://example.com/def#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix hydra: <http://www.w3.org/ns/hydra/core#> .
>
> rdfs:seeAlso rdfs:range :SomeDocument ;
>    hydra:supportedOperation [
>      a hydra:Operation ;
>      hydra:method "GET" ;
>      rdfs:label "Fetch the related resource" ;
>      hydra:returns rdf:Resource
>    ] .
>
> As we have the AAA idea, I'm perfectly allowed to make these statements in my
> API docs and I would imagine it's reasonable for a user of my API to assume
> these statements hold true for the scope of my API, but not necessarily
> elsewhere. Perhaps this is not according to currently accepted LD best
> practices, or conflates the idea of trust and scope, but IMHO makes for a
> elegant and intuitive approach.

I think I've seen the exact problem brought up a few months ago on the 
list. AFAICT the conclusion was that your second snippet is valid, 
because these triples would only ever be discoverable from the 
ApiDocumentation. Thus we shouldn't worry that 3rd party vocabularies 
get hijacked.

>
> Comments/flames welcome :)
>
> John
>
Received on Monday, 12 January 2015 17:58:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 12 January 2015 17:58:14 UTC