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

Hi,

> On January 12, 2015 at 6:57 PM 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?

The example was a little bit too simple, maybe better would be to think of a
class like foaf:Person and property like foaf:knows.
Another example is to be able to somehow describe that resources of type
foaf:Person or in object position of foaf:knows can be DELETEd in my API without
having to make a sub-class and sub-property of foaf:Person and foaf:knows
respectively.

>
> 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
> >
>
>