What is the right term for the Filter / QueryBuilder concept?

[danielbeeke]

We have shui:Viewer, shui:Editor and now we need to find a good name for the Filter / QueryBuilder concept described in #16.

An example could be:

shapes:Person
    a sh:NodeShape ;
    sh:targetClass schema:Person ;
    rdfs:label "Person"@en ;

    sh:property [
        sh:name "Family name"@en ;
        sh:path schema:familyName ;
        sh:datatype xsd:string ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        shui:filter shui:TextFilter ; <-----------------this issue is about the 'filter' part of these names.
    ] .

This would give a form that shows a text input, typing 'Baker' in that text input would ultimately generate a SPARQL query which would filter to schema:Persons that have the schema:familyName of 'Baker'.

How shall we name this concept?

Please vote with a thumbs up

[danielbeeke]

shui:Filter

[danielbeeke]

shui:Facet

[danielbeeke]

shui:FacetFilter

[danielbeeke]

Something else..

please describe in a new comment and vote for it

[tfrancart]

shui:Field

Why ?

1. sometimes the component to edit/create a new value and to filter/search on a value, is the same. In the simple case of a text field, it will be the same. Will we declare one shui:TextEditor + one shui:TextFilter ? or a single shui:TextField that could be declared in both situation. Same with shui:ListEditor + shui:ListEditor vs. shui:ListField.
2. we are describing form components / fields - the component / field does not have to know whether it is used for creation or filtering
3. http://www.w3.org/ns/ui uses the terminology "Field"

I would keep sh:filter for the property name. So:

shapes:Person
    a sh:NodeShape ;
    sh:targetClass schema:Person ;
    rdfs:label "Person"@en ;

    sh:property [
        sh:name "Family name"@en ;
        sh:path schema:familyName ;
        sh:datatype xsd:string ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        shui:filter shui:TextField ;
        #   shui:editor shui:TextField ;
    ] .

[bergos]

@tfrancart We should not compare it with properties and classes defined in the ui namespace. That namespace was designed for a lower level. We want to define components on a higher level and already have Viewer and Editor superclasses. It should be possible to identify the possible usage of components based on the superclass to defined constraints. The linked implementation is a different story. It may support multiple use cases.

If you support using filter for the property, why not also use it for the class?

[tfrancart]

If you support using filter for the property, why not also use it for the class?

Because I think the same UI component can be used for different purposes.

But let's gof or shui:Filter and see how things progress, I don't want to slow down discussions.