Jump to content

Search the Community

Showing results for tags 'dln:cc beta v1.0.3'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • FAQ
    • Project Information
  • Digital Lab Notebook (DLN) software
    • DLN Core functionality
    • Inspector tool (integrated in the DLN)
    • SIP Archiver (integrated in the DLN)
  • Capturing Data
    • Dome Method
    • Highlight Method
    • Photogrammetry
  • Processing RTI Data
    • Processing RTI Data
    • RelightLab
  • Viewing and Analyzing RTI Results
    • All Viewers
    • Dissemination
    • RTI AHRC Project (UK)
  • Regional Cultural Heritage Discussions
    • Nigerian Cultural Heritage

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 13 results

  1. Dear Developers, The DIGIT department from the Royal Library of Belgium (www.kbr.be/en) is interested to make use in a sustainable way of the software DLN:CaptureContext v.1 Beta. Nevertheless, DIGIT dept. has two requirements for the metadata stored in the PostgreSQL DB cpt_db : • Does DLN:CC support to work with a DB cpt_db hosted on a PostgreSQL server, rather than locally ? If so, is there a way to do so (DB client / server relationship on a local network) ? • Does DLN:CC support to read & write on a common DB shared among several DLN:CC workstations (multi-clients with one shared DB hosted on a PostgreSQL server) ? Does the Cultural Heritage Imaging intend to offer those features for a forthcoming stable release ? Thanks and regards for your dedicated work, Thierry F.
  2. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Location entries need a ‘Notes’ section like most other registers Whilst some well-known institutions and monuments may have entries in the Getty Thesaurus of Geographic Names, possibly the majority of locations will not appear therein, or at least with insufficient granularity. Need field(s) in which the address can be entered. As mentioned by IainS earlier, the ‘GPS coordinates’ field needs provision to record information on projection etc. Need a field to use to store local coordinates and type thereof Suggest allow recording of EPSG code for sets of co-ordinates, and also ability to have local name for a co-ordinate system (e.g. “OSGB36(15)”)
  3. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Stakeholder’s rights are currently linked to a subject and I would query that. A subject is, say, an artefact, and in possibly the majority of cases, there’s no copyright in the object/artefact/subject, the copyright is in the work which documents it. If, say, Organisation A has a Greek sculpture on public display, and they commission a 3-D scan, and organisation ‘B’ has a photogrammetry/RTI campaign, and organisation ‘C’ takes a series of close-up images to document some specific details. Organisation A is linked to the subject as, say, its curator – but has no automatic rights to any representations of it. Organisation ‘A’ may well, though, have rights to the 3-D scan they commissioned. Organisation ‘B’ will probably have rights to their photogrammetry/RTI, and organisation ‘C’ will probably have rights to their documentary photographs. As the linkage is currently to the subject, then in the above case there may be three competing and possibly contradictory rights linkages, one from each organisation, and there would be no way to differentiate which set of images etc. was covered by which rights statements. Whilst there may (more rarely?) be a rights linkage between a stakeholder and a subject or artefact, I would suggest that as the rights really apply to a set of images or similar, it would be better to allow a rights statement to be associated with, say, an acquisition project rather than with the subject – that way it avoids possibility for competing/contradictory rights claims on a subject. Dave
  4. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Fully appreciate that the priority in the first beta was to expose all the functionality, but structure of the Dashboard might benefit from reorganisation - order? titles? move ‘paramaterisation’ items to a ‘Setup’ menu? System tray icon – when the focus is not on DLN:CC, the icon is just a blank white sheet – suggest something more meaningful would be useful – maybe something like the blue notebook DLN logo used on the web pages? or the CHI logo? Capture Teams – there are traces of ‘Teams’ (e.g. in export) but no UI access that I can spot anywhere in the dashboard. Suspect that Teams were at one point in there (something like equipment subassemblies) but have since been dropped, with which I personally would agree. Needs either maintenance and ability to use, or remove Teams from DLN:CC ?
  5. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 When creating or modifying entries on the reference lists, there doesn’t appear to be any check on whether a duplicate is being created. DLN:CC appears to (universally as far as I can see) allow the user to create duplicate entries. In the case of, say, Operator Roles, one can create two roles both called Supervisor. When one comes to associate Operators with an Image Set, you have to pick a role for the association, and you will see two indistinguishable Supervisor roles to choose from, and even if the tooltip / description had been populated, it isn’t visible. In some cases there may legitimately be multiple items such as tripod or light stand, but that would be covered by having Quantity > 1 in the equipment record as there would be no need to differentiate between them. I can envisage relatively few cases where near-duplicate entries might be required – but they would still need visually distinct names to allow them to be correctly associated. For example, if a user had two camera bodies of identical model, but different serial numbers – and the user wished to keep track of which body was used on a shoot because of the age of the body, or perhaps different firmware. Two equipment records could be created – but unless there was something distinctive about the names, the user would not know which body to associate with the image capture. It should be relatively easy for the alert user to monitor this on small lists (especially once they are sorted alphabetically) but once lists get longer, or perhaps a DLN:CC instance has multiple users, the risk of inadvertent creation of duplicate entries will increase. I would strongly suggest that DLN:CC shouldn’t allow creation of any records with identical names. List ‘shuffles’ – a disconcerting phenomenon – only seen, I think, on the Equipment Overview list. If you open the Equipment Overview and then highlight a row and click [Details], or double-click a row and then [Close] the details screen, the underlying list remains exactly unchanged. However, if you open the details and then change something (not necessarily the Name) and then click [Save], when you then [Close] the details screen, the entry you clicked on has, at first sight, disappeared! On further inspection though, it has either moved to display row 9 or the bottom of the list. This is somewhat disconcerting! If the operator has manually sorted the equipment list before activating & changing details, then the list seems to survive un-molested in the chosen order (unless the list was alphabetical and the name has changed in which case the resultant change to maintain alphabetical order is performed correctly).
  6. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 On the Image Set screens, as well as the ‘Created’ dates, it also exposes two date fields captioned ‘Data entry some time within’. At first, as these are only (as far as I can see) on image sets, I wondered if ‘Created’ was the capture date and ‘Data entry’ was the date on which the images were processed to build an RTI model or photogrammetric product. However, the ‘data entry’ fields are read-only, and appear to be some form of internal audit record which has both start and end date auto-populated with the date on which the record was keyed in DLN:CC? Suggest: ‘Created’ date might be better captioned ‘Capture’ date to make it clear it relates to the date the images were captured, not when the DLN record was created Audit fields not displayed elsewhere, so not needed here? It would, though, be useful to allow recording of date on which image sets were processed? (also, previous comments / discussions on date formats apply)
  7. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 On many list displays (e.g. Category/Type/Role) the first column of the tabular display, to the left of the ‘ID’ field, is a monotonically ascending integer which I suspect is a display index of some kind, which could be useful for debugging but can’t envisage functionality for normal users, and similarity in values with those in the ID column could potentially be confusing. Is this un-named column necessary? / should it be hidden or zero-width? Default sort order – appreciate that lists can be sorted by clicking on the column-head label, but would suggest that a consistent approach is taken to the order in which items are sorted for display when a screen first opens. This is currently not the case, for example: Equipment Categories defaults to alphabetically by name Person Overview appears to default to ascending ID Equipment Overview appears random – neither alphabetical or in ID order The list of Role options when associating an Operator with an Image Set - neither alphabetical or in ID order I would suggest that alphabetically A..Z for the ‘name’ of the item would be a reasonable and useful default.
  8. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 This is initially relates to silent corruption of a field in the Equipment Overview, but may have wider implications… If one is using DLN:CC Equipment Overview as a mini asset register as per the sample database, and populates a price, there are silent and insidious problems if one enters anything other than digits 0 to 9 or a decimal point by including say a currency symbol (e.g. £ for GBP) or a comma (used by many to delimit thousands, or in some regions as the separator twixt the integer portion and decimal fraction of a real number). What happens is: On the equipment overview details screen, the data entry field (whether adding a new record or editing an existing record) allows one to enter costs such as 123.45 1234.56 1,234.56 1.234,56 £123.45 £1,234.56 GBP 123.45 without any objection either when the Price field is exited or when the [Save] button is clicked. However, if one then saves, closes and goes back to view the record details, in all except the first two cases, the Price is now ‘0’. Without seeing the code, from the above it appears the failure is because the UI is accepting (meaningful and valid) ‘text’ but the database is only accepting a real with a decimal point separator. Insidiously, the whole database INSERT / UPDATE isn’t failing – if for example the serial number and price are changed, the serial number is saved/updated but the price can be corrupted to 0 if it contains anything except 0 to 9 or a decimal point. Couple of points: As there is unlikely to be any arithmetic on equipment prices, in this specific case might be best to just make the Price column in the database a text varchar, rather than numeric, column. More importantly though: 2. If there are restrictions as to what can be stored in a field, the UI needs up-front validation either when the field is exited or when the [Save] button is clicked. 3. IF the UI is posting the input from the user intact and it is being rejected by the database, then it raises the possibility that the result of commands which modify the database may not be being monitored. Dave
  9. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 A tick-box ‘Show associated’ appears in the Filter block on a number of screens. I fully understand this is a beta; I can understand what ‘Show associated’ does, but I’m not sure if it is needed (as much / at all), and if it is needed, its placing on the screen and its nomenclature. The data in DLN builds the database by associating, say, equipment, operators and documents with a project or image set. In pretty much every case, as it is a normalised database, one operator or document can be associated with multiple projects. What is in question here is the view ‘from the project’ side – and from the project perspective, the question of how many, and how, the higher-level objects are associated with, say, a project. ‘Show associated’ appears when the operator is given the opportunity to link higher-level objects with, say, a project. In the current beta, the left-hand pane displays a list of items that can be associated, and the right-hand pane displays a list of those have (already) been associated. Items can be added to and removed the associated list, and the corresponding entry appears/disappears in both right and left hand panes; the list on the left shows those that have not already been associated. The current system effectively operates a default mechanism to allow one of each type of entry to be associated with the project; ticking the ‘Show associated’ box populates the left-hand list with all possibilities, not just those which have already been associated. First two points: The ‘Show associated’ tick box is in the Filter pane at the top of the display, which otherwise filters the right-hand list – it would (if/when still needed) be more intuitive if ‘Show associated’ was above the left-hand pane which it influences, alongside the title of the left-hand list. The tick box’s name ‘Show associated’ would be more meaningful as ‘Show already associated’ (if/when still needed). Looking deeper though, I would question the need for ‘Show associated’ in many cases. Taking a few examples: Linking a Document to a Project – this, when established, is a direct, unqualified link. There would be no sense in linking the same document to the same project more than once, so having ‘Show associated’ on that screen is not needed. In this case, ‘Show associated’ isn’t needed. Linking Equipment to an Image Set - this, when established, is a direct, unqualified link. In this case though it is possible that multiples of the same item are used. The equipment list will probably be significantly ‘longer’ and only ‘shrink’ a little when an item is associated, so having ‘Show associated’ on that screen is of minimal benefit. If helpful validation was to be offered, then when an item is being associated, quickly check if it has already been associated and pop-up a quick message to ask the operator to confirm they wish to associate a second instance. Linking a Stakeholder to a Project – this establishes a qualified link as a role must be selected at the time the stakeholder is linked to the project. The default only allows a Stakeholder to be associated once; if a second role needs to be documented, the ‘Show associated’ needs to be ticked so that the stakeholder can be selected a second time and a second association recorded. However, there are no checks that a pre-existing role isn’t being duplicated, so by ticking ‘Show associated’ it is possible to accidentally assign a meaningless duplicate role. In this case, some safeguard is needed but ‘Show associated’ isn’t really the most appropriate – I would suggest the Stakeholder list is always left fully populated (i.e. no ‘Show associated’), and when an association is being created the pop-up linkage details screen either automatically limits the list of roles to those ‘… NOT IN …’ the existing, or quickly check before saving that it isn’t a duplication. So, 3. I would query the appropriateness or need for ‘Show associated’ as the data model is refined. Just to repeat, these are suggestions which could only be made after the valuable first beta; and I fully appreciate workflow and data model will evolve. ‘Show associated’ allowed testing to progress and these comments to be made! Dave
  10. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 In addition to the technique-specific fields on image sets, currently: there is an unformatted free-form ‘Notes’ or ‘Description’ field/area on many of the register screens; the Equipment Overview has a number of hard-coded auxiliary fields, which are enabled in specific cases if the equipment is a lens / lens filter, or illumination source / illumination filter; and the Subject Overview screen has an option to populate four free format label:value pairs, one of which whose label indicates it is intended to be ‘is part of’. The auxiliary fields on the Equipment records have fixed purpose and are stored in hard-coded columns. However, the auxiliary fields on the Subject are to all effects uncontrolled. As it stands, the user, on a per-subject basis, decides on the purpose they wish to use the field for that single subject and types in what they want the field name / item label to be and then types in the value to be stored – both of these are totally free format. What this means is that these auxiliary fields are, I would argue, of possibly even less value than the free-format Notes field – whereas the auxiliary fields could actually be so much more useful…. With the current system, there are two issues: There is no control over the labels, so on one record the user could type in “Gift of” as the title or label for the first field (as in the sample data), and on another subject, they could type in the first field’s label as “Donated by” or “Donor”. If the user then sought to search for all records where label1 = “Donor” … then they would miss ones where the label had been typed as “Gift of” or “Donated by”. (as it happens, I suspect “Gift of” as cited in the example database might actually be better as a stakeholder role, but the “Gift of” serves well to illustrate the point.) Also, as there is no control over which of the fields is used, even if there was standardisation to call an entry, say, “Catalogue number”, as that could be stored in subject auxiliary field 1, 2 or 3, then any query would have to be some form of (… WHERE subject_id1_lbl = ‘Catalogue number’) UNION (… WHERE subject_id2_lbl = ‘Catalogue number’) UNION ( … WHERE subject_id3_lbl = ‘Catalogue number’) As it stands, having the free-format labels and data fields allow highlighting (a bit like having the ability to underline or embolden text in the Notes field) but doesn’t contribute as much as it could in terms of structured data. I think that a simple change could resolve these, and add to the power of DLN. Instead of having multiple auxiliary fields embedded in the Subject rows, store the auxiliary data in a linked table, and control the list of possible labels via a ‘label type’ register?
  11. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Other UI comments / across multiple registers: Deleting, for example, equipment entries – there is no check for dependencies so equipment which is associated with an image set can be deleted / referential integrity is not enforced. Would expect [Ctrl][F4] to activate [Close] as it does for almost every other Windows application Would expect [Esc] to activate [Cancel]/[Close] Some maintenance screens have an explicit [Close] button, others don’t To see / update details, some maintenance screens have button [Details], others have one called [Edit] Even without the use of accelerator keys, would suggest not ideal having three visually-similar buttons adjacent to each other [Details] [Duplicate] [Delete] Associating e.g. equipment with image set – currently works by highlight then click [ >> ] – it would be good if it also responded to the commonly used double-click to move. Where there is a sub-assembly, this allows filtering of the left-hand list. Would be good to be able to just associate the entries on the list. Filter block - most maintenance screens just have a [Clear] but some have an explicit [Filter] button? Filter block - several maintenance screens have [Export RDF] in the Filter block? File / About - more usually under Help / About? File / About - make the text on the screen so it can be copied and pasted into error reports etc. to ease reporting / accuracy
  12. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 1) If the user, when updating an equipment entry, just edits the Notes, [Save] is not active - you need to activate [Save] by ‘touching’ another field 2) The ‘Category’ filter resets without clicking clear (as soon as you click [Save]) 3) When creating or editing an equipment record, the [Tab] key skips the serial number field
  13. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Appreciate Rights included by default relate to the twelve promoted by ‘Rights Statements’ – but they’re not necessarily either applicable or appropriate, and they don’t necessarily apply in all jurisdictions either (and even the ‘Rights Statements’ organisation recognises that their twelve not universally applicable). Appreciate you don’t want anyone tampering with those twelve, but think probably need to allow for others to be added/edited as well.
×
×
  • Create New...