Define/change the range of "supportedProperty"

[lanthaler]

Currently, the range of hydra:supportedProperties is hydra:SupportedProperty. Sam proposed to change it to also allow rdf:Property directly without having to go through the indirection of a hydra: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?

[RubenVerborgh]

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.

[lanthaler]

Take #26 into consideration when resolving this issue

[lanthaler]

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:

• Is "supportedProperty" still needed in this case?
• Should "property" and "propertyPath" be combined?
• Should this information still be bound to a class or should we introduce a wrapper similar to the current SupportedProperty?

[dschulten]

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.

[dschulten]

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