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

On 02/03/2014 06:27 PM, Markus Lanthaler wrote:
> On Tuesday, January 28, 2014 6:18 PM, Thomas Hoppe wrote:
>> On 01/26/2014 08:04 PM, Markus Lanthaler wrote:
>>> On Friday, January 24, 2014 3:24 PM, Thomas Hoppe wrote:
>>>> 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.
> Well, if you have nothing else you have to yes. It would probably work in a
> lot of cases but not all. If a vocabulary uses a different resource for each
> concept such as, e.g., Schema.org or FOAF do you wouldn't be able to find
> other properties as soon as you reach the root unless each resource also
> documents inverse relationships. To make this more concrete. If you start at
> http://schema.org/reviewBody you could navigate back to
>
>    http://schema.org/Review
>    http://schema.org/CreativeWork
>    http://schema.org/Thing
>
> but from there you wouldn't find your way to, let's say
> http://schema.org/Product in the general case as there's no link from Thing
> -> Product. The link is from Product -> Thing.
Agreed but why would I want to do that, at least in the case of schema.org?
The Classes seem to exhibit a strict OO style without multiple inheritance.
So if you collect all properties while climbing up to the root
(granted that the reverse relationship that you mention is somehow known.),
you should have everything you need if you want to determine the 
supported properties.

>
>> 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 see. If schema.org where to adopt supportedProperties this problem would
> go away if I understand you correctly.
That would be one way but I think you would agree that adhering to the 
seperation of
concerns principle (things schema vs. API vocab) this cannot be a solution.
What I'm seeking is a way to leverage the existing vocabularies without 
mixing in other vocabs (hydra in this case).
And here I'm especially concerned with the, let's call it "supported 
properties problem" (don't re-enumerate each property from a used class).
 From the other discussions on the list I see there is much more to it 
than just getting a list of
them but I think for a good portion of the use-cases this would keep 
things easy and foster adoption.
>
>
>> I think a possibility would be to do this in some sort of preprocessing
>> and not at runtime.
> Sure, you can implement a lot of heuristics but we can't base a spec on
> them.
That's definitely not a spec topic! I raises this rather from a user's 
perspective
put in simple worlds:
How can I solve this problem today, given Hydra and for example schema.org?
>
>>>> 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.
> Are we looking at the same file? I just downloaded it and can see stuff like
>
>      <owl:DatatypeProperty rdf:about="http://schema.org/isbn">
>          <rdfs:label xml:lang="en">isbn</rdfs:label>
>          <rdfs:comment xml:lang="en">The ISBN of the book.</rdfs:comment>
>          <rdfs:range
> rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
>          <rdfs:domain>
>              <owl:Class>
>                  <owl:unionOf rdf:parseType="Collection">
>                      <rdf:Description rdf:about="http://schema.org/Book"/>
>                  </owl:unionOf>
>              </owl:Class>
>          </rdfs:domain>
>      </owl:DatatypeProperty>
Yes and from this you learn that every property is a 
`http://www.w3.org/2000/01/rdf-schema#Literal`
which is not too concise if you look into the Web page of our example 
you see the
`Values expected to be one of these types` field which describes for 
each literal whether it's
a string, number, date time or whatever and this is what I meant when I said
"So with this vocab you cannot infer a single property data type.".
>
> in it. AFAIK the OWL file isn't up to date. You should look at
>
>    http://schema.org/docs/schema_org_rdfa.html
>
> instead or directly extract the data from the schema.org definition pages.
> Here's the data extracted from http://schema.org/Product represented as
> JSON-LD and Turtle:
>
> http://rdf-translator.appspot.com/convert/detect/json-ld/html/http%3A%2F%2Fs
> chema.org%2FProduct
> http://rdf-translator.appspot.com/convert/detect/turtle/html/http%3A%2F%2Fsc
> hema.org%2FProduct
>
> Please not that schema.org uses schema:rangeIncludes and
> schema:domainIncludes instead of their RDFS counterparts.
>
> [...]
>>>> 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.
> I'll write a separate mail about this. It might indeed make sense to relax
> the range of "expects".
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Monday, 3 February 2014 22:18:35 UTC