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

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?

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