Restrict Facets based on selection in Table

[ashbyb]

regarding the ontology restriction first someone needs to right click a column, and select a new option "restrict ontology based on selection".

if someone drops an object property, then restrict the class tree, to get this call: queryClassesInPropertyRange

if someone drops a class, restrict which properties that class is allowed in the range restriction of can be returned. for this call: getPropertiesClassCanRange

[apseyed]

So, when this is functional, if a user drops an object property and there is no class dropped in the same column, and the user enables the "restrict ontology based on selection" context menu option, the class's shown in the jstree will be at the parent that is the most general class that is in the object property range.

This guides the user is specifying what more precise class under the OWL class in the range the cell values are instances of. We need to be sure not to suggest that the class cannot be outside of that restriction, its only that it must also be in that restriction, given open world.

Inversely, if a user drops a class and there is no object property yet dropped in the same column, and the user enables the "restrict ontology based on selection" context menu option, the property shown will be that which is the most general set of properties that the class is in the object restriction of. Once again, it is not a constraint as much as it is a guide, and also uses restrictions in the ontology but without showing axioms.

I'm testing this now and will give you the green light for client side shortly.

[apseyed]

currently testing:

(load dcterms first)

$.bbq.pushState({"classesInPropertyRange":"http://purl.org/dc/terms/accrualPeriodicity"}); AnnotatorModule.queryClassesInPropertyRange({}, function(d){console.debug(d)});

$.bbq.pushState({"propertiesClassCanRange":"http://purl.org/dc/terms/Frequency"}); AnnotatorModule.getPropertiesClassCanRange({}, function(d){console.debug(d)});

this is working, we are finalizing rendering in the gui

[apseyed]

Evan has suggested the following:

"the fastest solution might be to have a method that will give a set of active URIs for each tree, and then use jQuery to crawl the tree and hide any

elements where the hierarchy_id attribute is not in the active set."

"resetting is a bad idea because you basically prevent the client from caching the data. it's much more efficient to just hide the classes you don't want than to remove them from the tree and have to repopulate at a later time"

"i guess another alternative might be to hide

if it has no children and hide the if the

does have children. this will make the parents effectively disappear, but it won't fix the indentation"

"i'm wondering if we could use a more subtle UI trick, such as bolding relevant classes, so that they can see the class in the context of the class hierarchy. using PATH_TO_NODE, the tree will expand to show the class(es) named in the range. there's even a mechanism that will scroll to the named element"