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
Comments
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. |
PROPOSAL: Add a 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. |
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 |
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? |
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 ofhydra:search
could be introduced. The semantics would be that a template (pseudo-code)that is expanded to
would return a collection in which all members correspond to the following graph pattern
The text was updated successfully, but these errors were encountered: