This page is not meant to be complete nor to give proper introduction. We will build a developer guide on the vocbench site when we have enough material. For now, this acts as the reference place where to put behind-the-stage information about VocBench.

Services Invoked for Concept/Term Descriptions

these descriptions come from the (now concluded) stories:

Concepts

user is in front of the concept details panel

• initially, the sole services invoked are:
  • vocbench#getConceptTabsCounts() : for getting the number of triples for each tab
  • the service populating the term tab because it is the one which is initially presented to the user
• then, whenever the user clicks on one tab, one service is invoked per that tab. This service depends on the tab type (see below)
• in any case, the output of these services is consistent along all tabs: it is a list of predicate-objects entities; that is, for each tab, you get a list of properties, and for each property, there is a collection of values
• a feature of these services is that whatever the method used to filter the properties to be shown, these properties need to be represented only if they have values (Andrea Turbati check here, as the previous version of the getValuesOfProperty/ies(...) returns even empty properties.
• then, next step: get the template properties, that is, those properties which have at least one of the types of the resource being shown (usually a concept) as their domain, filtered out still by the type of tab (for instance, the attribute tab gets all the datatyipe properties (getTemplateProperties role=datatypeProperty) ), but not really all the datatype props, but only those which have (in the specific case of the concept details panel) skos:Concept as their domain
• regarding visualization: for the client, apart from specifyng it in the request (in the future, not now), things do not change in handling the response, as it will always be the "show" field of the property serialization to tell the client which string to show
• NOT NOW: when the user clicks on one of these template properties, a service is invoked for getting ack of the fact that the property can be given a value (we will implement it, checking also various other checks, but I suggest to ignore it for the moment, as we can deserve it major thinking).
• then, after getting the ack (NOW: just ignore the above and get immediately to this point after the user clicks), getRange() is invoked. getRange is enough for knowing what to do: it contains the set of classes in the range, and, in the case of datatypes, the nature: plainLiteral, typedLiteral, or just literal (which maybe any of those two). Only in the case of dataranges, it may require to invoke property#parseDataRange() to get the list of possible values (you can inspect the whole process on ST on Firefox, by seeing the sequences of calls on the error console).
• in case of simple literal (just "literal") the client asks to the user which kind of value he's going to produce
• oh, the explicit/nonexplicit thing has still to be implemented in these methods. Please implement it in any case on client side (just the greying), so we can plug a newly working ST even if this is done after you depart.

Now, details for each tab:
Terms: at the moment it is implemented through vocbench#getConceptDescription(). I would separate it in some information for getting info about the XLabels, but fine for now.
Definition: vocbench#getConceptDefinition() is hold be skos:definition, it is a specifc method to reflect the particular structure of this definition
Note: getValuesOfProperties(), excluding skos:definition 
Attribute: getValuesOfDatatypeProperties()
Relationships: getValuesOfProperties() rooted on skos:related
History: getConceptInformation (internal method, probably recalling a past service, such as vocbench#getConceptDescription() ), and a call to resource#getValuesOfProperties with properties=dcterms:created||dcterms:modified||agrontology:hasStatus.
Image: analoguous to Description, but with Images (vocbench:getConceptImage())
Hierarchy: seems to make only internal calls, probably by using the tree information

A service called: vocbench#getConceptTabsCounts() specifically designed for the vocbench UI, will give an overview of the counts for the single tabs. Since it is specifically designed for VB, it does not need customization through parameters, as it already takes into account for th customization brought into the single tabs.

Important Note
the previous VB model was assuming that everything is inside SKOS, while a SKOS thesaurus may use relationships out of the SKOS model...this is of particular importante in the relationship tab...

Terms

The tabs are only:
Attribute: getValuesOfDatatypeProperties(), same as for conceptdetails, but obviously with term as the subject
Relationships: getValuesOfProperties(), but this time rooted on skosxl:labelRelation
History: getConceptInformation (internal method, probably recalling a past service, such as vocbench#getConceptDescription() ), and a call to resource#getValuesOfProperties with properties=dcterms:created||dcterms:modified||agrontology:hasStatus.

A service called: vocbench#getConceptTabsCounts() specifically designed for the vocbench UI, will give an overview of the counts for the single tabs. Since it is specifically designed for VB, it does not need customization through parameters, as it already takes into account for th customization brought into the single tabs.

Important Note
the previous VB model was assuming that everything is inside SKOS, while a SKOS thesaurus may use relationships out of the SKOS model...this is of particular importante in the relationship tab...