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

On 2015-01-12 21:00, John Walker wrote:
> 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.

ApiDocumentation does it all. And I don't think subClass and subProperty 
is not necessary. See my earlier reply below.

>
>  >
>  > 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 20:18:52 UTC