Re: Decoupling statements about a class in hydra from the original class

Hi Dietrich

I think it's safe. The statements about the class are only present in ApiDocumentation. It cannot be accidentally crawled, because the URL is only shared in the Link: header. Thus it's not possible that these statements leak to the outside world.

Also how else would you describe an API which reuses other vocabularies. If your model is

{
  "@type": "http://schema.org/Person",
  "http://schema.org/giveName": "Tomasz"
}

If you were to subclass sch:Person and sub-property sch:givenName to decouple from original terms you inadvertently end up with a different model. For that reason I would even say that subclassing to decouple should be discouraged. 

After all it should be you data model that drives your design and not the other way round.

One other possibility would be to declare SupportedClasses without stating their @type but rather adding a hydra:class property. Again, this would be much like supportedProperty/property

{
  "supportedClass": {
    "class": "schema:Person",
    "supportedProperty": {
      "property": "schema:givenName"
    }
  }
} 

This way the third-party terms aren't hijacked.

Regards,
Tom

January 14 2015 9:05 AM, "Dietrich Schulten" <ds@escalon.de> wrote: 
> Hi,
> 
> in Hydra we say that a SupportedOperation expects a type, and we make statements about that
> expected type, e.g. by saying which properties are supported.
> 
> Since sometimes the expected type might be a type from a third-party vocab, we want to make it
> clear that the statements about the type apply only within the current API.
> 
> I want to be sure I understand how we decouple our statements about an expected class from the
> original class.
> 
> Within a sample response [1] I have found the following idiom. The expected class appears to be an
> rdfs:subClassOf schema:Rating:
> 
> "method": "POST",
> "expects": {
> "@type": "Class",
> "subclassOf": "Rating",
> "supportedProperty": [
> {
> "@type": "SupportedProperty",
> "property": "ratingValue",
> "required": true
> },
> {
> "@type": "SupportedProperty",
> "property": "reviewBody",
> "required": false
> }
> }
> 
> Is the subclass necessary here for decoupling or could I use "@type":"schema:Rating" like below,
> without inadvertently making statements about every schema.org Rating class or causing other
> problems?
> 
> "expects": {
> "@type": "Rating",
> "supportedProperty": [
> {
> "@type": "SupportedProperty",
> "property": "ratingValue",
> "required": true
> },
> {
> "@type": "SupportedProperty",
> "property": "reviewBody",
> "required": false
> }
> } To me it seems I am safe, after all the subject of :supportedProperty is not identified (has no
> @id, i.e. it is a blank node), I merely say it is an rdf:type schema:Rating and I say that the
> blank node has two supported properties
> 
> (putting aside the fact that schema:reviewBody normally "belongs" on a schema:Review, not a :Rating
> and we have not decided yet how to express this kind of nesting, see #37 and #26).
> 
> Best regards,
> Dietrich
> 
> [1] http://www.hydra-cg.com/spec/latest/schema.org/

Received on Wednesday, 14 January 2015 09:34:36 UTC