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

On Apr 25, 2014, at 10:29 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Thursday, April 24, 2014 7:47 PM, Gregg Kellogg wrote:
>> On Apr 24, 2014, at 7:31 AM, Markus Lanthaler wrote:
>>> This goes much further than searching or filtering collections. It's really
>>> querying them (or the complete API for that matter). For the moment, yeah,
>>> it is out of scope I would say as we have to get the other things right
>>> first. But I do see this as a potential future work item.. maybe for a Hydra
>>> Query vocabulary. If you want take a stab at it.. we can certainly also
>>> start working on that sooner. I just don't want us to be distracted to much
>>> till we get the basics right.
>> 
>> Best leave it to the future, then. There are enough tough knots to chew on
> right now.
> 
> OK, I've added it to ISSUE-20 for the time being:
> 
>  https://github.com/HydraCG/Specifications/issues/20
> 
> [...]
> 
>>> Currently, you can't associate templated links to a type and then have it
>>> applied on all instances of that type. The templated link needs to be
>>> associated with the instance. The reasoning behind that decision is that
>>> each templated link will likely look different (at least the template). If
>>> you just append query parameters, that assumption doesn't hold though.
>>> Should we raise an issue for this?
>> 
>> Yes, I think this is a serious shortcoming, and violates the DRY principle. If I have 20
>> properties upon which I may interact, and a couple of different ways to filter them, not to
>> mention define operations on them, repeating this information in each instance can consume
>> a large percentage of the HTTP payload. This is where some of my attempts at defining
>> templates presuming either the URL of the resource to be affected, or have a way to
>> reference that URL to form a URL based on it. Relative-URL arithmetic may make this
>> difficult unless every resource ends in "/", which may be too big of an assumption.
> 
> 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.

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 think we need other restrictions such as owl:oneOf and owl:allValuesFrom anyway, so this is in keeping with that.

Gregg

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

Received on Friday, 25 April 2014 19:25:04 UTC