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

On Monday, February 03, 2014 11:18 PM, Thomas Hoppe wrote:
> On 02/03/2014 06:27 PM, Markus Lanthaler wrote:
> > 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?

Yeah, schema.org is really a special case.


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

Strictly speaking you wouldn't be able to find any property (again, not true
for Schema.org because each type-page includes also the properties) because
it is the property that links to the type and not vice versa.


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

Why would that be a violation of concerns? You would just make the links
that every Schema.org page already contains from the type to its properties
machine-readable. That has nothing to do with an API description. It's just
a link in the reverse direction.


> What I'm seeking is a way to leverage the existing vocabularies without
> mixing in other vocabs (hydra in this case).

The Schema.org partners are actively discussing to include this concept (and
a few others from Hydra) directly into Schema.org. See:

  http://bit.ly/1ik8LNm


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

Right. But due to the way RDF(S) works there's no other solution I'm aware
of. As already said, you can achieve a lot by heuristics etc. but they don't
work reliably enough to base a spec on.


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

You link types to the properties known to be supported in your API by using
hydra:supporterProperties. I know that's not the answer you are looking for
but the only other alternative, which is specific to Schema.org, is to
create an inverse-index of schema:domainIncludes to get the set of your
"supported properties" for each type.


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

Right, as I already said

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

There [1] you will find the information you are looking for (fixed some
errors, the translator seems to be a bit buggy):


  @prefix s: <http://schema.org/> .

  s:isbn rdf:type owl:Property,
         rdf:type rdf:Property ;
     s:domainIncludes s:Book ;
     s:rangeIncludes s:Text ;
     rdfs:comment "The ISBN of the book."@en ;
     rdfs:label "isbn"@en .


Is this the information you were looking for? If you look at [2] you will
see what I meant with the reverse-index.


[1]
http://rdf-translator.appspot.com/convert/detect/turtle/html/http%3A%2F%2Fsc
hema.org%2Fisbn
[2]
http://rdf-translator.appspot.com/convert/detect/turtle/html/http%3A%2F%2Fsc
hema.org%2FBook


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 4 February 2014 17:26:55 UTC