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

Hi Dietrich,

Sorry for late response.

January 14 2015 6:10 PM, "Dietrich Schulten" <ds@escalon.de> wrote: 
> 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?
>

You may be right. I wonder what others 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 don't think that blank nodes help at all. If we use supportedProperty on third party class and this gets crawled and combined with other operations attached to the same class, we're still in trouble. Sort of. Whoever crawled multiple such disconnected API documentations, would have to assume that all the operations are valid on all instances of a given class. 

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

I don't think I was right about changing the semantics. One way or another we annotate RDF classes and properties. If you merged multiple ApiDocumentations you always end up with these annotations all mixed up. I don't think there is anything we can do about that as long we want to avoid owl:subClassOf.

>> 
>> Regards,
>> Tom
>>

Received on Monday, 26 January 2015 08:17:14 UTC