The default register
/system/typed-templates
includes entries for dataset and URIset, but the .vm files for these are not present in the distribution.
(concept-scheme-render.vm is, however.)

Steps to reproduce:

1. Build a LDR instance with a baseURI that includes a path following the domain
   • in our case http://environment.data.gov.au/def
2. login, open edit dialogue, make a change, select [Save changes]
   --- Save failed: Bad Request - Payload URI does not match target ---

Inspection of the request URL shows that an extra /def has been inserted in the URL.
When this is removed, everything is fine.

Looks like perhaps the algorithm for building the request URL has parsed some input to find the end of the domain, rather than the end of the baseURI ??

I noticed that

I've implemented some UI simplifications in response to various user feedback. This is aimed at making routine registry admin (create a register, upload or patch a set of entries using e.g. a CSV) easier for non-experts. For example, by hiding some more advanced features in the "advanced" menu and by packaging standard options as drop downs/radio buttons.

As part of this I've restructured the velocity templates area to improve structuring and make them easier to maintain.

I've also restructured how the main CSS file is generated to make it easier to customize the look and feel. This is based on using sass to generate a customized bootstrap and add core registry styles. In doing so I've updated the default look and feel to be more compatible with GOV.UK styling.

This forms the basis for new deployments of the UK Environment and Location registries (e.g. see http://environment.data.gov.uk/registry - though without a login the UI changes other than look&feel aren't visible).

This is all currently in branch ui-restructure.

Now that this work has completed and there are a couple of instances in production I'd like to merge this into master. I know that @marqh at least uses registry-config-base as an upstream so that a merge would mean your next rebase might be a little different from normal. So I'll hold off the merge for a short time until we have a chance to confirm it is acceptable.

When a registry contains multiple hierarchical schemes each of which may reference common terms from another register, the tree view of a register presents multiple entries of a child item, one for each of the registers that references the item within its hierarchy. This occurs because in the hierarchy view, the query embedded within main/_hlist-render-child.vm locates the reg:RegisterItem associated with the child entity and it is a link to that item that is then presented to the user.

Suggest replacing this line in main/_hlist-render-child.vm (layout adjusted for readability)

#set($query="SELECT DISTINCT ?item WHERE 
             { <$concept> $narrow ?entity.  
               ?entity ^reg:entity/^reg:definition/^version:currentVersion ?item 
             } ")

with

#set($query="SELECT DISTINCT ?item WHERE 
             { <$concept> $narrow ?entity. 
               { SELECT ?entity (sample(?i2) as ?item) WHERE 
                 { ?entity ^reg:entity/^reg:definition/^version:currentVersion ?i2 } 
                 GROUP BY ?entity 
               } OPTIONAL { 
                 ?entity rdfs:label|skos:prefLabel ?label 
               } 
             } ORDER BY lcase(?label)")

By wrapping the second half of the query in a SELECT... GROUP BY construct enable the (random) selection of a single reg:RegisterItem (?item) for each referenced entity which then eliminates any duplication of identical items in the tree view.

In addition there is an added probe for labels under an OPTIONAL in order to alpha sort the nested elements of a the tree view which makes a more deterministic and navigable presentation particularly if a parent node has many children.

A PR will follow offering an implementation of the suggested change.

Hi, we are a group at mdl/nws/noaa is USA. The users of our registry app prefer the "Browse" mode of the registry to be a default view. That is, each time a user visits the registry homepage, he wants to see the "Browse" view instead of clicking the "Browse" menu at the top of the app's gui. Can someone tell us how to set this up? Thanks!

The listing of item versions in a history is sorted using the alpha sequence.
This is OK for 9 or fewer versions, it gives an unexpected display for more versions.
E.g. see

http://registry.it.csiro.au:49178/sally/_Kurosols

and select the History tab.