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

>> [...]
>> 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.
 From what I know schema.org is a vocab to make content machine readable 
(mainly from a seach engine perspective)
and not a vocab to describe APIs and see below....
>> 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
Well this is not what I consider a sound approach for "inclusion" 
because they just copy over
stuff like with Goodrelations instead referencing referencing them like 
in usual for ontologies.
Put as offensive question: Why are they not using Hydra if they need a 
concept like supported property.
>> 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.
Definitly, there are ways to heuristically deduce them, such as 
considering the context as a template
of a resource as 'template' but that's of course not I was looking for.
Yes, I got it, it is impossible, at least using RDFS.
>>>> 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.
> 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
Yepp that's at least what the Web page shows up for human users and 
obviously you can scrape this from
the RDFa as you said before. However, I hope that they come up with a 
OWL which is on par.
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Tuesday, 4 February 2014 22:25:51 UTC