- From: Dietrich Schulten <ds@escalon.de>
- Date: Wed, 14 Jan 2015 09:03:57 +0100
- To: "public-hydra@w3.org" <public-hydra@w3.org>
- Message-ID: <54B622ED.3080902@escalon.de>
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 08:04:43 UTC