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

> > Following this train of thought one would also have to question the added
> > value of the hydra:Link class instead of using rdf:Property or
> > owl:ObjectProperty.
>
> 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.

Comments/flames welcome :)

John

Received on Monday, 12 January 2015 12:39:30 UTC