- 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