- From: Thomas Hoppe <thomas.hoppe@n-fuse.de>
- Date: Tue, 28 Jan 2014 18:18:14 +0100
- To: public-hydra@w3.org
Hi Markus, On 01/26/2014 08:04 PM, Markus Lanthaler wrote: > 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. ok, you are right from an RDF standpoint I could throw in any property but see my reasoning below. > > 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. sure, that's what I meant with 1.) >> 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. But you could infer the reverse through an `rdfs:definedBy` or similar owl definitions of a property -- which might semantically not be correct but you could use this information if you have nothing else. And here is my reasoning for this: As I mentioned before, I'm intrigued by the idea that I can leverage existing date models using LD/ Semweb assets like schema.org but If I need to enumerate each and every property for my own API, I've lost parts of the advantages. I'm seeking for a way to prevent this. I think a possibility would be to do this in some sort of preprocessing and not at runtime. > >> 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. > I know that there is one (http://schema.org/docs/schemaorg.owl) and I'm using it for a while now. What I mean is that there are zero `owl:DataPropertyRange` definitions, not a single use of `xsd:...` So with this vocab you cannot infer a single property data type. >> 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 Yea, I saw it after my mail :) > 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. Ok, this sounds like a good idea because an API consumer won't get screwed up with thinking about why property X is not part of the supportedProperty list or why it does not "subclass" class Y although you are using properties from its domain. > > >> 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 Tuesday, 28 January 2014 17:18:44 UTC