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

Hi Thomas,

On Friday, January 24, 2014 3:24 PM, Thomas Hoppe wrote: 
> 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

You can do something like that in practice (at least for schema.org) but in
theory it is the wrong approach. In RDF's data model, on which schema.org is
based, all properties are allowed on every class unless explicitly stated
otherwise. That's exactly the reason why I introduced supportedProperties in
the first place.

Schema.org is a bit of a special case here since it uses
schema:domainIncludes instead of rdfs:domain. domainIncludes is weaker as is
doesn't tell you anything about an instance which uses such a property. On
the other hand, if you have a property with a rdfs:domain definition, you
can infer the type of an entity that uses that property.

> vocabulary find out
> which properties exist (RDFS, OWL definitions),

You would need to crawl the complete vocabulary. The problem is that there
are no links from vocabulary -> class, class -> property, just the other way
round.

> 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.

It definitely simplifies things as you just use a library but it's not too
complex to implement these things yourself.


> 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.

What do you mean? That there's no single file containing the complete
schema.org vocabulary? There is one.. I'm offline at the moment but I'm sure
you can easily find it by Googling for "schema.org RDFa full" or something
like that. Furthermore, I believe each schema.org page contains all
definitions in the form of RDFa or Microdata (unable to check right now).
Since each class' description contains also the description of all
superclasses you won't even need to navigate up the class tree.


> Cons:
> This approach is obviously problematic as the technological and
> computational efforts are very high.

I would say, in general almost impossible.

> 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.

If you need it from a single place, that's true. If not, you can navigate up
the class tree and include the supportedProperties of superclasses. This is
underspecified at the moment. I'm leaning towards not doing that by default
but could be convinced otherwise.


> 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.

That's exactly the same as in Hydra. In practice you won't use
CreateResourceOperation etc. We discussed that in the past and I see this
confuses many people. Probably we'll thus remove them altogether from the
core vocab.

> Concepts like a `WebFormHandler` could be used to model

Yeah, depending on which version of the draft you look at it either uses
requiredProperty/optionalProperty or supportedProperty without going through
an indirection of a class. In fact, Sam raised that point again a [5] couple
of hours before your mail. In my opinion the additional nesting due to that
indirection is a small price for the potential gain. In the worst case,
simply use an anonymous class (a blank node) which just defines it's
supportedProperties.. Sam did that in his interesting demo and also
specified the superclass of that anonymous class.


> 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]

See above. I think you can get both things at the same time at a very small
price.


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

Yes, they are. Thanks for your analysis. The only thing that's missing is
your personal opinion. Which approach are you leaning towards and why? In
other words, what's important for you?


Cheers,
Markus


> [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

[5]
http://www.w3.org/mid/CAMtUnc5cvdXMxagupT6TDwbEQVvjSd54KfqSBxxHM-ChJ694HA@ma
il.gmail.com


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 26 January 2014 19:05:01 UTC