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

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.


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


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


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

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 17:28:22 UTC