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

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

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


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 27 April 2014 14:34:57 UTC