Open lanthaler opened 10 years ago
My main issue: how do we know whether the argument of hydra:supportedProperties
is an rdf:Property
or a hydra:SupportedProperty
? We need to know this to act accordingly.
In the general case, this question cannot be answered without (possibly levels of) dereferencing.
Take #26 into consideration when resolving this issue
PROPOSAL: Change the range of "supportedProperty" to "rdf:Property" and introduce something like "constraint" (and rename "SupportedProperty" to "PropertyConstraint") to define the usage of a property in the context of a specific class. A concrete definition would then look something like this:
{
"@type": "hydra:Class",
"supportedProperty": [ "rdf:type", "schema:name", "schema:address" ],
"constraint": [
{
"@type": "PropertyConstraint",
"property": "rdf:type",
"allowedValue": { "@id": "schema:type" }, <--- doesn't exist yet
"required": true
},
{
"@type": "PropertyConstraint",
"property": "schema:name",
"required": true
},
{
"@type": "PropertyConstraint",
"property": "schema:addressCountry",
"propertyPath": [ "schema:address" ], <-- doesn't exist yet
"required": true
}
]
}
There are still a couple of open questions that we should discuss:
I must say I liked the non-flattened proposal in #26 better (the one with :supportedRange). First, I am not so sure about the property paths. They do not allow to say things about a path component. In this case: maybe the :address is not required - only if it is in the request, it requires an :addressCountry. Besides, flattening only makes the markup more concise if there are very few nested properties.Otherwise it leads to duplicated paths. Second, in #26 the constraint is immediately attached to the property, whereas here the client has to look up the constraint for a :supportedProperty.
One more thing: Could you please explain what the :allowedValue property means? I cannot dereference schema:type, maybe that is the reason I do not understand it.
The property paths have a different, quite compelling use case: If I want to define which property is bound to an IriTemplate variable, I do need a property path for something like Event.location.name
Currently, the range of
hydra:supportedProperties
ishydra:SupportedProperty
. Sam proposed to change it to also allowrdf:Property
directly without having to go through the indirection of ahydra:SupportedProperty
as it allows much more concise markup.Is that a good idea? Does it have any negative side effects in practice? What are the trade-offs?