Re: Decoupling statements about a class in hydra from the original class

Hi Tomasz,

thank you for the reply on the side, during the heated discussion about 
hydra:Class :-)

On January 14, 2015 10:35:04 AM "Tomasz Pluskiewicz" <tomasz@t-code.pl> wrote:

> Hi Dietrich
>
> I think it's safe. The statements about the class are only present in 
> ApiDocumentation. It cannot be accidentally crawled, because the URL is 
> only shared in the Link: header. Thus it's not possible that these 
> statements leak to the outside world.

That is not quite what I meant, I was talking about an operation which is 
defined within the json response as in [1], not about a definition in the 
ApiDocumentation.

The fact that the Link Header points to the ApiDocumentation  is in itself 
not a way to guarantee isolation of our hydra-related statements IMHO. I 
would specifically *expect* a crawler for Rest APIs to dereference the Link 
Header to the ApiDocumentation, and if it has a reasoner inside, we must be 
sure we are not stating things about external classes we don't mean to.
Also, there is no rule that Link Headers should normally not be crawled.

What do you think?

My feeling is, we are still safe because we say things about blank nodes 
which describe an expectation for our Api, not the external classes.

I want to understand fully how we decouple, that is the background of my 
question.



>
> Also how else would you describe an API which reuses other vocabularies. If 
> your model is
>
> {
>   "@type": "http://schema.org/Person",
>   "http://schema.org/giveName": "Tomasz"
> }
>
> If you were to subclass sch:Person and sub-property sch:givenName to 
> decouple from original terms you inadvertently end up with a different 
> model. For that reason I would even say that subclassing to decouple should 
> be discouraged.
>
> After all it should be you data model that drives your design and not the 
> other way round.
>
> One other possibility would be to declare SupportedClasses without stating 
> their @type but rather adding a hydra:class property. Again, this would be 
> much like supportedProperty/property
>
> {
>   "supportedClass": {
>     "class": "schema:Person",
>     "supportedProperty": {
>       "property": "schema:givenName"
>     }
>   }
> }
>
> This way the third-party terms aren't hijacked.
>
> Regards,
> Tom
>
> January 14 2015 9:05 AM, "Dietrich Schulten" <ds@escalon.de> wrote:
> > Hi,
> >
> > in Hydra we say that a SupportedOperation expects a type, and we make 
> statements about that
> > expected type, e.g. by saying which properties are supported.
> >
> > Since sometimes the expected type might be a type from a third-party 
> vocab, we want to make it
> > clear that the statements about the type apply only within the current API.
> >
> > I want to be sure I understand how we decouple our statements about an 
> expected class from the
> > original class.
> >
> > Within a sample response [1] I have found the following idiom. The 
> expected class appears to be an
> > rdfs:subClassOf schema:Rating:
> >
> > "method": "POST",
> > "expects": {
> > "@type": "Class",
> > "subclassOf": "Rating",
> > "supportedProperty": [
> > {
> > "@type": "SupportedProperty",
> > "property": "ratingValue",
> > "required": true
> > },
> > {
> > "@type": "SupportedProperty",
> > "property": "reviewBody",
> > "required": false
> > }
> > }
> >
> > Is the subclass necessary here for decoupling or could I use 
> "@type":"schema:Rating" like below,
> > without inadvertently making statements about every schema.org Rating 
> class or causing other
> > problems?
> >
> > "expects": {
> > "@type": "Rating",
> > "supportedProperty": [
> > {
> > "@type": "SupportedProperty",
> > "property": "ratingValue",
> > "required": true
> > },
> > {
> > "@type": "SupportedProperty",
> > "property": "reviewBody",
> > "required": false
> > }
> > } To me it seems I am safe, after all the subject of :supportedProperty 
> is not identified (has no
> > @id, i.e. it is a blank node), I merely say it is an rdf:type 
> schema:Rating and I say that the
> > blank node has two supported properties
> >
> > (putting aside the fact that schema:reviewBody normally "belongs" on a 
> schema:Review, not a :Rating
> > and we have not decided yet how to express this kind of nesting, see #37 
> and #26).
> >
> > Best regards,
> > Dietrich
> >
> > [1] http://www.hydra-cg.com/spec/latest/schema.org/
>
>

Received on Wednesday, 14 January 2015 17:11:16 UTC