Open david-batranu opened 11 years ago
HI, yes the result_display method of displaying results is quite basic. For more complex displays - or as in this case for displays of data with complex keys, it would probably be better to use the post_search hook to get the result data into a custom js function that builds the result object onto the page in the desired way, and not bother using the result_display structure at all.
@markmacgillivray , thanks! I just want to give some context on why we have URI as keys for anybody interested for semantic/RDF data indexing.
our overall architecture is as follow. we are using a RDF store (openlink virtuoso) as an integration server where we have data from many systems. Than we are creating a Semantic RDF River Plugin for Elasticsearch (https://github.com/eea/eea.elasticsearch.river.rdf) that can query SPARQL endpoints and index RDF data into ES. Than we are trying to use the okfn facetview to give a nice faceted search to the end-users.
This is already working nicely except from the fact that keys from a semantic point of view are URI so that we can distinguish between two fields with same representation but different meanings, e.g. http://xmlns.com/foaf/0.1/Person#name vs http://myownvocabulary.com/vocab/Chemical#name one is the name for a person the other is a name for a chemical ... therefore URI containing the namespace (=ontology context) will differentiate these two field and we avoid clashes.
My aim as manager of this project at EEA is to contribute to this okfn product and avoid keeping a fork of it...so I really hope we can improve the original facetview to be more robust and flexible concerning the result data having more RDF alike values like URIs or json-ld style, making facetview displaying linked data a become a nice tool for building semantic web applications.
_it would probably be better to use the postsearch hook
If I'm not mistaking, the call of post_search is not properly implemented - the this
object is the jQuery Ajax call object itself, it doesn't hold the response object or parsed search results.
options.post_search_callback.call(this);
this
is jQuery.ajax() closure and can not be used to render results.
By the time the callback runs though, the query has executed and dumped the result data into the options. So you can write a callback that refers to the options of the facetview instantiated on the element, and get all the data you need from there.
Thanks, I didn't think that through :)
result_display formatting doesn't work and filters don't show when URIs are used as field names, for example, in the result below, "http://purl.org/dc/terms/creator" is used instead of "author", since currently the code assumes
.
is used to get data from an object, the split turnshttp://purl.org/dc/terms/creator
into["http://purl", "org/dc/terms/creator"]
and breakes the functionality.I forked the code and did a quick fix but my fix will not allow things like
http://purl.org/dc/terms/creator.first_name
to work, since it skips the split.In the fix some jQuery selectors have been replaced with
[id=""]
syntax, as selectors likejQuery('#facetview_http_//purl_org/dc/terms/creator')
don't seem to work using the standard syntax.