Category Archives: Mint2

Data report templates description

Mint2 Reports 5 Comments

simple xlsx detail reports:

  1. mint2organization_transformation.jrxml
  2. mint2organization_publication.jrxml
  3. mint2organization_oaipublication.jrxml
  4. mint2organization_import.jrxml

organization details :

  • mint2OrgDetailsubreport.jrxml :

subreports :

  1. mint2uploadsubreport.jrxml
              • subreport : mint2derivedtransformationssubreport.jrxml
  2. mint2mappingsubreport.jrxml
  3. mint2transformationssubreport.jrxml
  4. mint2publicationssubreport.jrxml
  5. mint2oaipublicationssubreport.jrxml

organization goals details:

  • mint2orgDetails3.jrxml :subreports :
  1. mint2transformationssubreport2.jrxml
  2. mint2publicationssubreport.jrxml
  3. mint2oaipublicationssubreport.jrxml
  4. mint2goalssubreport.jrxml

project goals overall :

  • mint2progress.jrxml

project details overall :

  • mint2OrgStatsubreport.jrxml

16 + ( 2 common templates) = 18 jrxml files .

Mint 2 Data Reports

Mint2 Reports No Comments

Mint2 now supports a data reporting system.

The implementation is based on the Jasper Reports library.

The Report Layout is described by a Java object in our case already compiled into a .jasper file that resides into to the Mint instance runtime path.

These .jasper file have been compiled into binary from an XML file describing the report layout. Designing .jrxml (Jasper Reports XML) report files and compiling into the .jasper objects can be done with the use of an almost WYSIWYG editor like iReport .

Jasper Reports library uses multiple sources as its input. Our implementation uses custom Java beans as an input.

iReport can read the fields of the report input Java Beans through a .jar exported from Eclipse and placed inside iReport’s path.

The .jrxml files although not used at runtime ,in our reports are placed inside the project directory /report_templates. Editing can be made with iReport and the resulting compiled .jasper should be put in the WEB-INF/src/java/gr/ntua/ivml/mint/report.

Retrieval of the data is made through the UrlApi of Mint2 .This allows the reporting system to be ported and run independently by an application, such as a central reporting system, monitoring multiple Mint2 project instances.

At runtime Java beans are constructed after parsing the UrlApi JSON responses corresponding to our requests.

After the JSON is parsed custom Java beans are created and added into Java Collections by classes called factories.

The Collections (Lists) are input into the Jasper Report manager (net.sf.jasperreports.engine.JasperFillManager ) along with the specific .jasper file and some optional parameters .

Output can be in various formats with the use of various libraries. For .xlsx or .csv types the report has to be designed in a minimal way without using much graphics or vertical spaces.

Our report system is implemented into the DownloadReport action. And all the classes describing the Java Beans and the factories are placed into the : WEB-INF/src/java/gr/ntua/ivml/mint/report/

 

 

 

Hidden previews

XSD Schema 2 Comments

Preview configuration properties support hidden views. They will be used to generate subsequent views, but they will not appear in the UI.
To hide a view add the hide property:

"preview": [{
    "xsl": "edm2ese.xsl",
    "label": "ESE",
    "output": "xml",
    "hide": true,
    "preview": [{
        "xsl": "ese2html.xsl",
        "label": "Europeana",
        "output": "html"
    }]
}]

In this example, Europeana will be generated based on ESE, but ESE will be hidden.

Single.action

Kaiten Mint2 UI 4 Comments

I created a new action called Single to facilitate opening single kaiten panels by accessing a URL. In order to use it, you have to specify the action, the action parameters and an optional kTitle. For example, to directly open mapping tool with specified parameters, you can access

/Single.action?action=DoMapping.action&transformationId=1077&kTitle=Mapping+Tool

This will redirect to:

/Home.action?kConnector=html.page&url=DoMapping.action%3F%26transformationId%3D1077&kTitle=Mapping+Tool

which is essentially the same. The added value is that you can type the url without worrying about escaped characters in the url.

Mint2 Annotator

Annotator 7 Comments

I just commited the first implementation of the Mint2 annotator. In order to run it, you have to put this in your local.properties.

ui.hide.annotator = false

You can then select any dataset in your workspace and select the Annotate option. Alternatively, you could visit the generic Mint2 instance we have on oreo.

The annotator is based on the editor setup of the mapping tool and uses a similar structure for representing the object in memory. It doesn’t save the changes in the database yet, items are only stored in memory for now. Items loaded are not currently linked to a schema, so it is not possible right now to add elements that do not already exist.

So, have a look and we can discuss things in the comments 🙂

Meta table

Database Mint2 8 Comments

The Meta table in Mint2 is a key value store that can hold information not important enough to end up in their own tables.

Basic access to this table is handled by these static methods:

  • Meta.put( String key, String value ): Stores a value for the specified key. Replaces the value if the key exists.
  • Meta.get( String key ): Gets a value for the specified key or null if the key does not exist.
  • Meta.delete( String key ): Deletes entries with the specified key.

The Meta API has also been extended to support storing properties related to database persistent objects. It uses reflection to generate a key based on the object’s class name, the object’s getDbID method and a property name. The generate key has this form: Class[dbID].property. The following methods are supported:

  • Meta.put( Object object, String property, String value ): Stores a value for the specified object/property pair. Replaces the value if the property exists for this object.
  • Meta.get( Object object, String property ): Gets a value for the specified object/property pair or null if the it does not exist.
  • Meta.delete( Object object, String property ): Deletes property of the specified object.
  • Meta.getAllProperties( Object object ): Gets a list of tuples with all object’s properties and their values.
  • Meta.deleteAllProperties( Object object ): Deletes all properties for the specified object. Useful if the object is going to be removed from the database.

An example of using Meta, is storing user preferences for the mapping editor:

User user = ... /* some user object */
DB.getStatelessSession().beginTransaction();
Meta.put(user, "mapping.preferences", "some string value that holds user preferences");

The key generated for this object/property pair is gr.ntua.ivml.mint.persistent.User_$$_javassist_12[1000].mappings.preferences, where 1000 is the dbID.
The preferences are later retrieved by using:

Meta.get(user, "mapping.preferences");

When the user is deleted, the following should also be called:

DB.getStatelessSession().beginTransaction();
Meta.deleteAllProperties(user);

Schematron support

Mint2 Validation XSD Schema 4 Comments

Mint2 now supports validation using Schematron rules. Schematron rules are related to an XmlSchema instance and can be provided to the system through appinfo schema annotations, using external schematron files, or both.

Define schematron rules

You can define schematron rules inside an XSD by adding an appinfo annotation like this (example from ORE.xsd):

<element name="Aggregation">
  <complexType>
    <annotation>
      <documentation>Aggregated CHO: a link to the original CHO plus a new provider</documentation>
      
      <appinfo xmlns:sch="http://purl.oclc.org/dsdl/schematron">
        <sch:pattern name="Either Is shownby or is shownat should be present" >
          <sch:rule context="ore:Aggregation">
            <sch:assert test="edm:isShownAt or edm:isShownBy">A ore:Aggregation must have either edm:isShownAt or edm:isShownBy</sch:assert>
          </sch:rule>
        </sch:pattern>
      </appinfo>
      
    </annotation>
    ...

Alternatively, you can provide schematron rules using external schematron files. If the schematron schema configuration property is defined, the system will first try to locate this file in the same directory the XSD file exists. Otherwise it will try to locate a file with the same name as the XSD file with a .sch suffix (i.e. EDM-INTERNAL.xsd.sch). The system will also try to merge rules defined from xsd and external files.

Schematron validation

Schematron validation is available by using the gr.ntua.ivml.mint.xsd.SchemaValidator class. This class provides variants of the validateSchematron(Source source, XmlSchema schema, ReportErrorHandler handler) method to validate source using an XSL generated by the schematron rules related to the schema XmlSchema. If a handler ReportErrorHandler is provided, errors will be added in the handler’s schematronErrors JSONArray:

Schematron XSL generation

The schematron XSL used to validate an xml is generated by the gr.ntua.ivml.mint.schematron.SchematronXSLTProducer class by using the getXSL method.
This requires a string that contains a complete schematron document. Rules from XSD appinfo annotations can be wrapped in a complete schematron document by using the wrapRules method and using the schema’s namespace declarations (from schema’s configuration) to include in the document:

XmlSchema schema = <an XmlSchema instance>
String schematronRules = schema.getSchematronRules();

SchematronXSLTProducer schematron = SchematronXSLTProducer.getInstance();
String wrapped = schematron.wrapRules(schematronRules, schema.getConfigurationNamespaces());
String xsl = schematron.getXSL(wrapped);

Preview configuration can use Crosswalks

Mint2 XSD Schema No Comments

I added the option to use Crosswalks in preview configuration. For example, instead of specifying the lido to ese XSL file in each preview configuration (and having to update it each time it was changed) we can instead provide the target schema name in the preview. Instead of using this preview configuration:

{
    "xsl": "lido-v1.0-to-ese-v3.4-transform-v3.xsl",
    "label": "ESE",
    "output": "xml"
}

we can use this:

{
    "target": "ESE 3.4",
    "label": "ESE",
    "output": "xml"
}

The ChainTransform object that generates the preview tabs will look for a direct crosswalk from the source schema to the specified target. This should use the same crosswalk used during publication, if the publication schema and preview schema names are the same. So we should be consistent on how to name installed schemas in Mint2 installations. I suggest we use the schema name in capital letters followed by the version (without a ‘v’ prefix) i.e. LIDO 1.0, ESE 3.4.

PS 1. If you omit the label parameter the preview tab will use the target schema name as tab title.
PS 2. In order to update our mint2 installations accordingly, I added the option to rename a schema in Administration > Manage XSDs (see here).

mint2.js common functions

Mint2 20 Comments

I added mint2.js to include javascript functions that could be used throughout the Mint 2 UI. It basically creates a global Mint2 javascript object that  currently includes the following:

Mint2.languages includes functions to associate language codes with language labels (used in thesaurus browser widget).

I will describe Mint2.documentation in a future post.