Re: ISSUE-45: Introduce hydra:filter (subPropertyOf hydra:search)

On Apr 27, 2014, at 8:15 AM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
> 
> Gregg, you forgot to CC the group. So include your complete mail (and my
> comments) below.
> 
>> On Sunday, April 27, 2014 4:58 PM, Gregg Kellogg wrote:
>>> On Apr 27, 2014, at 7:34 AM, "Markus Lanthaler" wrote:
>>> On Friday, April 25, 2014 9:25 PM, Gregg Kellogg wrote:
>>>>> You can bind operations to properties and classes, so that's not a
>>> problem.
>>>>> What you can't currently do, is to bind IRI template mappings to a
>>> templated
>>>>> link:
>>>>> 
>>>>>  :property a hydra:TemplatedLink .
>>>>> 
>>>>>  # this doesn't work! The range of :property is hydra:IriTemplate not
>>>>> xsd:string
>>>>>  /something :property "my/{template}" .
>>>>> 
>>>>>  # you need to do something like
>>>>>  /something :property [
>>>>>      hydra:template "my/{template}" ;
>>>>>      hydra:mappings ....
>>>>>   ] .
>>>> 
>>>> I explored this in my Querying collections email:
>>>> 
>>>> :InterestCollection a hydra:Class;
>>>> hydra:supportedProperty [
>>>>   a hydra:SupportedProperty;
>>>>   hydra:multiple false;
>>>>   hydra:property hydra:member;
>>>>   hydra:required false
>>>> ], [
>>>>  a hydra:SupportedProperty;
>>>>  hydra:property :searchInterestCollection
>>>> ], .
>>>> 
>>>> :searchInterestCollection a hydra:TemplatedLink;
>>>> hydra:search [
>>>>  a hydra:IriTemplate;
>>>>  hydra:template "{?collection}?likeKind={?kind}";
>>>>  hydra:mapping [
>>>>    a hydra:IriTemplateMapping;
>>>>    hydra:variable "collection";
>>>>    hydra:property :interestCollection;
>>>>    hydra:required true
>>>>  ], [
>>>>    a hydra:IriTemplateMapping;
>>>>    hydra:variable "kind";
>>>>    hydra:property :likeKind
>>>>    hydra:required true
>>>>  ] .
>>>> 
>>>> Although, I confused where the actual :searchInterestCollection
>>> property/value would go,
>>>> and it does seem that it needs to go within an instance of a
>>> :InterestCollection.
>>> 
>>> Yes
>>> 
>>> 
>>>> We could consider doing something like an owl:Restriction on
>>> :interestCollection that
>>>> requires :searchInterestCollection to have a specific value. I could
> then
>>> define that value in
>>>> the API and not have to repeat it in a collection instance.
>>>> 
>>>> We could instead define a value such as
>>>> 
>>>> :SearchInterestValue a hydra:IriTemplate;
>>>>  hydra:template "{?kind}";
>>>>  hydra:mapping [
>>>>    a hydra:IriTemplateMapping;
>>>>    hydra:variable "collection";
>>>>    hydra:property :interestCollection;
>>>>    hydra:required true
>>>>  ], [
>>>>    a hydra:IriTemplateMapping;
>>>>    hydra:variable "kind";
>>>>    hydra:property :likeKind
>>>>    hydra:required true
>>>>  ] .
>>>> 
>>>> Then define a restriction such as
>>>> 
>>>> :interestCollection;
>>>> rdfs:subClassOf [
>>>>   a owl:Restriction;
>>>>   owl:onProperty :searchInterestCollection;
>>>>   owl:hasValue :SearchInterestValue
>>>> ] .
>>>> 
>>>> (Although, there may be a Hydra-specific way to do this as part of a
>>> revised Constraint).
>>>> 
>>>> What this would do is say that if I have a :InterestCollection, I can
>>> infer that it has a
>>>> :searchInterestCollection property who's value is :SearchInterestValue,
>>> and thus not have to
>>>> repeat myself by actually manifesting this in each instance.
>>> 
>>> I see. That certainly works (already). You can do it without OWL by
> simply
>>> materializing that triple, which is very cheap to do for the server and
>>> eliminates the reasoning for the client. The issue however is that it
> could
>>> quite easily be misinterpreted as a link instead of a templated link (by
>>> humans):
>>> 
>>> {
>>>    "@type": "InterestCollection",
>>>    "searchInterestCollection": "/apidoc#SearchInterestValue"
>>>  }
>> 
>> It may be that saying TemplatesLink is a subclass of Link is wrong, or
> that they
>> are disjoint. It's the result of applying variable substitution to the
> template
>> which is a Link.
> 
> Right. That's the reason why TemplatedLink is currently *not* a subclass of
> Link. They are both subclasses of rdf:Property.

Sorr, on my iPad, and don't have the documentation in front of me. Do we need to assert that they are disjoint? If they are, then I don't see how a client would confuse the value of a TemplatedLink property with a Link.

>>> I think, it would be much more straightforward to allow the association
> of
>>> IriTemplateMappings to a TemplatedLink property and change from
> rdfs:range
>>> hydra:IriTemplate to schema:rangeIncludes xsd:string, hydra:IriTemplate.
>>> Then you could simply do something like this:
>>> 
>>> {
>>>    "@type": "InterestCollection",
>>>    "searchInterestCollection": "{?kind}"
>>>  }
>>> 
>>> with
>>> 
>>> :searchInterestCollection a hydra:TemplatedLink;
>>>    hydra:mapping [
>>>       a hydra:IriTemplateMapping;
>>>       hydra:variable "kind";
>>>       hydra:property :likeKind
>>>       hydra:required true
>>>    ] .
>>> 
>>> The downside is that it introduces variability and makes the
> implementation
>>> of clients slightly more difficult as the IriTemplate would have be
>>> "reconstructed".
>> 
>> Yes, but I think this is pretty clear, but requires more work on the
> semantics of TemplatesLink, IMO.
> 
> What's semantics is TempledLink missing?

That the result of manifesting a template to an IRI after variable substitution is a Link; I'm not sure how you might express this, though. Probably just claiming this in the spec is sufficient.

Gregg

>> Gregg
>> 
>>> --
>>> Markus Lanthaler
>>> @markuslanthaler
>>> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Sunday, 27 April 2014 16:31:13 UTC