We fielded several questions as part of our recent webinar (recording and slides available here): What is New in TopBraid EDG 6.4

The list below includes questions we were able to answer during the webinar as well as questions we did not get to in the webinar.

Questions and Answers:

Q1: Can an expired Announcement be reinstated?

Yes, instead of deleting an announcement, you can expire it by setting its end date. If, at a later point, you need to bring it back, simply remove (or modify to some date in the future) the end date.

Q2: Can we make a layout that includes the Map panel?

Yes. Any combination of panels can be saved for re-use as a new layout. You can also make a new layout to be the default.

Q3: Are there any changes to 6.4 that you did not demo in this webinar?

Certainly. We were not able to fit all changes into this webinar. Some notable new features that were not demonstrated include:

  • Significant extensions to the LineageGram – it now covers more asset types
  • Enhancement of the algorithm that suggests business terms for a data element – it now takes into account profiling statistics
  • Improvements to RDF+ reification e.g., better serialization format, support of ordering (indexing) of property values, GraphQL query of reified values
  • Merged form views for resources that are members of two unrelated classes – you can now see a view that combines all properties
  • Direct streaming import of RDF, as an option – it is suitable for large files as it is significantly (orders of magnitude) faster than regular import. However, it by passes validation, clean up and capture of the change history.

The best way to understand all changes is to read the release notes. Release Notes always include a log of all changes. For 6.4, release notes are available here.

Note that currently the log change only shows changes made before the beta. Several changes were made after the beta release, including some that we showed today. Release notes will be updated for the release to include all changes.

Q4: Can the SPARQL template query be run through a http end point?

Yes, if you select a query in the SPARQL Query Library panel and click on the link icon, you will see query’s URL. For the example demonstrated during the webinar, URL is:

http://localhost:8083/tbl/sparqlLibrary/geo/f189beba-55ca-41a2-9d5a-9b0a0f334337?language1=&language2=

Of course, for the server installation “localhost:8083” will be replaced by the server:port address. When calling this query, provide parameter values. For example:

http://localhost:8083/tbl/sparqlLibrary/geo/f189beba-55ca-41a2-9d5a-9b0a0f334337?language1=en&language2=ru

 

Q5: Is there a capability to Export taxonomy to Excel?

Yes, there are many pre-built options for exporting to Excel. These options exist in 6.3 and prior releases. So it is not something new for 6.4. 
On the Export tab of Taxonomies there is a pre-built export for the entire hierarchy. Further, using the Search panel, you can export all search results to Excel. This lets you select any columns you want in your Excel file and apply any search criteria to the output. See User Guide for documentation on the Search panel. The same export actions are possible for SPARQL query results.

If you need custom export logic that is not addressed by these pre-built options, we recommend taking a look at Active Data Shapes scripting.  This is new for 6.4.

 

Q6: Is there a support to import taxonomy/data graph from S3 bucket?

Not currently. There is support for connecting to S3 and cataloging documents stored there. These resources go into a Corpus collection that has a connector pointing to that S3 directory.

If you have RDF file stored in S3 that you need to load into EDG, you would first download it and them use the standard way of importing RDF. One improvement in 6.4 over 6.3 is that the RDF file could be zipped. If you are interested in importing RDF files from S3, please tell us more about your use case. For example, how often and under what conditions would such import occur? How would EDG know what graph to load a given file into, etc.?

 

Q7: Just tried the parametrized query. Very nice. One note of warning: don’t call your parameter the same name as a variable in the query. ?

Thanks. Yes, parameters in the query are special type of variables and all variables need to have separate names..

Q8: What is the inter-relationship between including attachments and content tagging module?

No relationship.
TopBraid EDG Content tagging module (Tagger and Autoclassifier) tags document resources that are cataloged by EDG with terms from controlled vocabularies. These document resources are instances of edg:Document class or its subclasses. The content itself remains in a content repository (which could be S3), but EDG crawls the content repository and creates a resource for each document. During this process metadata of the documents gets captured and the document text is scraped and converted into RDF to enable tagging. After tagging, document text (stored in the edg:content property) can be flashed.
The new attachment feature in 6.4 is not for tagging or text mining, it is to provide additional documentation about some resources in EDG. EDG does not create resources for these documents, it simply creates a relationship between some existing (user selected) resource in EDG and a document in S3 – because the document provides some additional information about a resource in EDG.
For example, you may want to create resources for the various data management policies e.g., data privacy, data retention, etc. You will then connect it to some data sources and/or processes that must comply with the policy. In a policy resource in EDG you will provide some summary description, but specific details of the policy will be in a document attachment.

Of course, if you already have a document management system that manages these documents, then, instead of using the approach we have demoed, you could use a property such as edg:documentLink and enter a URL of the document. However, some of our users asked us to support  managing attachments in EDG. To address such requirements we developed this new integration with S3.

 

Q9: When importing TriG files, how does EDG know what kind of collection to create for each graph? i.e. Data Graph vs. Dataset vs. Taxonomy?  

If the info is not there, it doesn’t know. The named graphs in the TriG file that follow the EDG naming convention for graphs (urn:x-evn-master:XY) will be turned into asset collections with yourself as the manager. Their type will be determined by what is specified for them in the file. Other named graphs will be turned into Turtle files in the workspace.

Note that access to TriG import is from the pages that list all asset collections of a given type e.g., all Taxonomies, Ontologies, Data Graphs, etc. 

 

Q10: When saving a default layout, is it possible to save and make default, the layout of the Search panel in EDG, specifically the table columns and the column selected as search filters?

Yes, this is another pre-existing option that is not for 6.4. You can select your result columns and search filters and then save your search as default. You do not need to enter any search criteria – leave it to each user to select.

Default searches do not have names. If you decide to change the default search later on, simply select a different set of options and save it as default – this will override the previously selected default.

Q11: Is it possible to have for different asset collections of the same type different default layouts?

This is partially possible. The default panel layout is selected per collection type and, optionally, per user. So, different users could have different defaults that best fit specific asset collections they typically work with. For example, one user may have a Map panel for taxonomies in their default layout because taxonomies they work with have spatial data and another user would not.

Further, many options that drive the panels, can be collection specific. This includes the default search view (as described above), the default root of the Asset Type navigator, the default selection for the Assets Hierarchy panel, etc.

Q12: How to hide the life cycle status of an asset?

We assume that this question is more generically about how to hide a property that has been declared for a given type of assets. Properties of an asset are defined in a corresponding ontology. If you do not control this ontology  (e.g., it is one of EDG’s pre-built ontologies), then instead of simply deleting a property, you should deactivate it.

The overall process for configuring EDG ontologies is as follows:
1. Either create an ontology or use an existing one – if you already have an ontology that you use to configure pre-existing models. Make sure it includes EDG shapes that define you asset type e.g., EDG Core Shapes, EDG Data Assets Shapes, etc.
2. Then, de-activate a property by:
  • Navigating to the class that defines your asset (e.g., Database or Glossary Term)
  • Clicking on the property you want to hide
  • Selecting, in the form that is shown,  “deactivate = true”.
  • Alternatively, you can select “hidden = true”
The difference between deactivated and hidden is that in the first case, EDG will act as if this field was never defined. In the second case, the field will be hidden in the form, but its data will still be validated.
Note that if you deactivate or hide an inherited property, it is deactivated or hidden at the point of its definition i.e., for all sub classes of the class where the property is defined.
3. After you complete your ontology changes, make sure that the ontology containing these model modifications is included in your asset collection.
You may also want to hide this field for only certain users. In this case, instead of step 2 above, do the following:
  • Create a new NodeShape
  • Set its “applicable class” to your asset type.
  • Copy property shapes from the applicable class for properties you want to keep in the view, but not for the ones you do not want e.g., not for the status property.
  • Select a governance role for this view. It could also make it default for all roles. With this approach, you are only hiding the property for this specific class – even if it is defined at a higher level.
For documentation, see: https://doc.topquadrant.com/6.3/ontologies/ and, more specifically, sections that discuss this are: