Wrap up and Discussion of ways to Specify Supported Properties and corresponding Validation Rules for Operations

Hi,

Following recent discussions about action handling and Schema.org 
Actions [1]
and personally asking for a way to describe/ introspect validation 
constraints [2],
I want to recap what we have and, what is in flux and hope for your 
opinions and contributions.

Wrap up of ways to specify expected properties for an operation that I'm 
aware of along with
a short discussion:

1.) Specify a Class with the `expects` property.

Discussion:
Sound linked data approach as it allows for concept sharing and also to 
share the data model of a concept.
For example of a `schema:Person`. A client could then dereference the 
class up to
its vocabulary to find out what properties are supported and from the 
vocabulary find out
which properties exist (RDFS, OWL definitions), of which data type they 
are (RDFS, OWL mappings on XSD types).
I'm not too deep involved with Semweb technologies but I think you will 
need a reasoner to
carry out this introspection purely from ontologies/ vocabs due to the 
various ways to define properties and
associated constraints.
Side note: I know that in the case of schema.org this would not even be 
possible as the OWL description
cannot be dereferenced and the existing OWL does not describe any simple 
properties.
Cons:
This approach is obviously problematic as the technological and 
computational efforts are very high.
Pros:
Very flexible, allows for completely generic clients for the "writable Web".

1.1.) You can use the `supportedProperties` property on a class to 
specify your specific needs
if the Class defines properties you do not want or you want additional 
properties
which are required in your very case.

Discussion:
This lowers the efforts of 1.) considerable as you can explicitly define 
the properties
and some meta-information like `required` or `readonly`.
Pros:
Mentioned above.
Cons:
You cannot extend an existing Class in typical OO manner;
effectively you need to redefine (or better remention) every property of 
the existing class again as `SupportedProperty`
so that a client can obtain all information from a single place.

2.) Use a non-hydra vocabulary which addresses this.
Currently I know about the efforts around schema.org  [1] [3] to model this.

Discussion:
Predefined actions could allow many Vendors to bind to unambiguous 
hight-level action
like a `schema:RegisterAction` rather than very generic operations.
Concepts like a `WebFormHandler` could be used to model

Pros:
Easy to grasp and good chance of interoperability
Cons:
Less generic and in my opinion very 'RPCish' which might compromise at least
the "cacheable" REST constraint [4]

I hope my assumptions are correct and my pro/ con discussions are 
comprehensible, please provide any input you have!

Greets

[1]http://www.w3.org/wiki/images/b/b9/Actionsinschema.org.pdf 
<http://www.w3.org/wiki/images/b/b9/Actionsinschema.org.pdf>
[2] 
http://lists.w3.org/Archives/Public/public-linked-json/2013Oct/thread.html#msg22
[3] 
http://help.yandex.com/webmaster/interactive-answers/form-description.xml#format
[4] http://en.wikipedia.org/wiki/Representational_state_transfer#Cacheable

Received on Friday, 24 January 2014 14:24:18 UTC