Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce hydra:filter (subPropertyOf hydra:search) #45

Open
lanthaler opened this issue Apr 19, 2014 · 4 comments
Open

Introduce hydra:filter (subPropertyOf hydra:search) #45

lanthaler opened this issue Apr 19, 2014 · 4 comments

Comments

@lanthaler
Copy link
Member

There are use cases like Ruben's Linked Data Fragments which need to filter collections. hydra:search is deliberately fuzzy to not restrict its usage unnecessarily and thus not always suitable. Sometimes it is necessary to filter a collection's members based on the value of their properties (not properties of their properties or similar things). To enable such use cases, a specialized subproperty of hydra:search could be introduced. The semantics would be that a template (pseudo-code)

hydra:filter [
  hydra:template "/collection?name={schema:name}"
]

that is expanded to

/collection?name=Markus

would return a collection in which all members correspond to the following graph pattern

?member schema:name "Markus"
@gkellogg
Copy link

Yes, this is something like I've been looking for; I'm not sure if aggregations are appropriate here, or would be left to search (probably the later).

You'll need to explain more about URI template variable binding; It seems that schema:name here is somehow used to find "Markus", perhaps in the subject of the collection, and that the "name" query element is interpreted by the service to be schema:name for members of the collection. It might be somewhat confusing if it has two senses that aren't directly related.

From a client's perspective, I would think that these variables would be used to drive HTML form fields, or similar. Is the purpose of specifying the predicate, then, to get the range and description to build such a form entry? Explaining the motivation behind doing this would be useful.

@lanthaler
Copy link
Member Author

PROPOSAL: Add a hydra:filter property with the semantics outlined above.

Question: If we decide to support "propertyPath" in "PropertyConstraint", should we also support propert paths in IRI template mappings? This would certainly make filter much more powerful.

@lanthaler
Copy link
Member Author

Gregg, please let's keep the discussion on the mailing list. Could you please repost it to the list creating a new thread with the subject "ISSUE-45: Introduce hydra:filter (subPropertyOf hydra:search)". Thanks

@alien-mcl
Copy link
Member

It seems that latest spec on GitHub has the hydra:search added. While I feel that in general whole IriTemplate stuff is more generic I see that having a quick & easy link that can be used without digging deeper would make some scenarios simpler. Unfortunately I've got lost in the conversations from the mailing list, thus I'm not sure whether this issue can be closed or there is anything else to do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants