RE: Nested supportedProperty

Hi again :-)

... and hi Holger, I CC'ed you to since this is directly related to the data
shapes work. As you'll see below, it would be great if you could give as a
quick status update.


On 13 Dez 2014 at 13:38, Dietrich Schulten wrote:
> 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",
>   }
> }

You have that with basically every vocabulary. 


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

Yes, it would make it simpler. The initial idea has been to leverage
rdfs:range for such use cases but it turned out to not really work in
practice. With Schema.org it obviously doesn't work at all since it doesn't
use rdfs:range but the weaker schema:rangeIncludes.


> {
>   "@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

In RDF and thus also in Schema.org properties aren't bound to classes as
they are in most programming languages. They stand on their own. So this
would be completely 
valid IMO. It gives the client enough information to construct the right
HTTP request.


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

That would be problematic indeed.


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

At the moment we can't really. We need to find a solution for this or, if we
are lucky, someone else will for us. The new RDF Data Shapes WG works on
exactly this. Unfortunately I'm not up to date with their work but Holger
(CC'ed) is quite active in that group and may have a couple of minutes to
give us a status update.


> {
>   "@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;

Nope, schema.org doesn't use RDFS and thus doesn't allow these inferences.


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

This is not maintained anymore AFAICT. It was a 3rd party effort in the
early days of Schema.org to get some RDF. Use the RDFa file you can find on
schema.org. I'm writing this offline on a train so I can't send you the
link, but I'm sure you'll find it easily.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 14 December 2014 19:45:34 UTC