Nested supportedProperty

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

in schema.org it is quite common to have nested types. E.g. a
reviewRating in a Review is actually of type (range) Rating. In
json-ld (copied from http://schema.org/Review):

{
  "@type": "Review",
  "reviewBody": "The lamp burned out quickly.",
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "1",
  }
}

That seems to pose a problem when I want to describe hydra:expects for
a review. If 'ratingValue' were not nested in a Rating class, but a
"direct" property of Review, I could say that the expected Review
supports two properties, reviewBody and ratingValue:

{
  "@context": "http://schema.org",
  "@type": "Product",
  "name": "Kenmore White 17\" Microwave",
  "review":
  {
      "@id": "http://example.com/products/2/reviews",
      "hydra:operation": [
      {
          "@type": "ReviewAction",
          "hydra:method": "POST",
          "hydra:expects":
          {
              "@type": "hydra:Class",
              "hydra:subClassOf": "Review",
              "hydra:supportedProperty": [
                {
                  "@type": "hydra:SupportedProperty",
                  "hydra:property": "reviewBody"
                },
                {
                  "@type": "hydra:SupportedProperty",
                  "hydra:property": "ratingValue"
                }
              ]
          }
      }]
  }
}

But that does not seem quite correct. A http://schema.org/Review has
no property 'ratingValue', rather its property 'rating' expects a type
Rating that has a property 'ratingValue'. It is not entirely wrong
either, because I define a subclass of Review to which I can assign
any properties I like without affecting the Review. But we lose
scoping that way. What If I expect a 'name' attribute top-level and a
nested 'name'?

This kind of nesting can go several levels deep. How can we handle
these situations? How can we tell a client that we expect a request
body with a nested ratingValue like this:

{
  "@context": "http://schema.org",
  "@type": "Review",
  "review" : {
    "reviewBody": "The lamp burned out quickly.",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "1",
    }
  }
}

So to answer an earlier question by Markus Lanthaler in a mail where I
tried to solve this problem by nesting hydra:supportedProperty, which
surprised Markus quite a bit :) ->

On 13 Okt 2014 at 17:25, Markus Lanthaler wrote:
> This would effectively say that a property supports another
> property. I think what you actually wanna say is that the value
> (range) of that property supports this other
property, > right?

Right :)

It might be that the proposal at
http://www.hydra-cg.com/spec/latest/schema.org/ has the same problem.
It defines a specialization of Rating:

    "expects": {
      "@type": "Class",
      "subclassOf": "Rating",
      "supportedProperty": [
        {
          "@type": "SupportedProperty",
          "property": "ratingValue",
          "required": true
        },
        {
          "@type": "SupportedProperty",
          "property": "reviewBody",
          "required": false
        }
    }

Here http://schema.org/reviewBody becomes a supportedProperty of the
expected subclass of Rating. No harm done so far. But if the client
were to construct this request based on the above expectation:

{
  "@context": "http://schema.org",
  "@type": "Rating",
  "ratingValue": 3,
  "reviewBody": "Gobbledigook"
}

One could infer that a Rating is also a Review since[1]
schema:reviewBody a rdf:Property;
    rdfs:domain schema:Review;
    rdfs:range xsd:string;



Best regards,
Dietrich Schulten

[1] http://schema.rdfs.org/all.ttl

- -- 
Dietrich Schulten
Escalon System-Entwicklung
Bubenhalde 10
74199 Untergruppenbach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iEYEARECAAYFAlSMM0EACgkQuKLNitGfiZNOSACfXdBl9xcADo2GWSZzdcRhYZnS
cPwAoPpA8w07CXPu77igPQGAqUbQhJI3
=TNOH
-----END PGP SIGNATURE-----

Received on Saturday, 13 December 2014 12:38:57 UTC