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

> On Jan 13, 2015, at 10:59 PM, John Walker <john.walker@semaku.com> wrote:
> 
> Hi Gregg
> 
> > On January 14, 2015 at 2:33 AM Gregg Kellogg <gregg@greggkellogg.net> wrote: 
> > 
> > 
> > > On Jan 12, 2015, at 9:57 AM, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote: 
> > > 
> > > 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? 
> > 
> > I think hydra:Link is quite useful, and supplementing a vocabulary definition within ApiDocumentation to say that, say, schema:url has the type hydra:Link is pretty minimal, if you consider that ApiDocumentation doesn't make universal claims, but only for this particular API.
>  
> Doesn't this largely depend on a decision about the hydra:Resource class? In that (even though it's not explicit in the Hydra Core vocab from what I see) the rdfs:range of a hydra:Link is hydra:Resource. W/out the hydra:Resource class, what does hydra:Link add that is not already covered by rdf:Property or owl:ObjectProperty?

The domain and range of hydra:Link could be the same as rdf:Property, but the documented semantics of hydra:Link could state that the value of such a property is de-referencable.

Gregg

> John
> 
> > 
> > If sentiment went against it, then we'd need something in Property Constraints to indicate that it is de-referencable. 
> > 
> > Gregg 
> > 
> > > 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 
> > >> 
> > > 
> > > 
> > 
> >