Forum Replies Created
That should be no problem! The most important things here are:
1. Import PersonID and PostId to your Person and Post Objects respectively in nodegoat. These IDs are used to establish relationships between Objects while you are importing relational data (e.g. in Object Descriptions called ‘Access Person ID’ and ‘Access Post ID’).
2. In your Data Model: make sure that you check the check-box ‘Use Description for quick search.’ for the Object Descriptions in which you have stored these IDs (the Object Descriptions ‘Access Person ID’ and ‘Access Post ID’).
You can now first import all the Persons and Posts separately (including their Access IDs). Once these two files have been imported you run a third import that connects People with Posts, using the data from your Career table. In this third import you use PersonID in the Career CSV file to identify persons. Map the column that includes this ID to the Object Description ‘Access Person ID’ and check the check-box ‘Use data from this column to filter similar Objects’ when creating the Import Template. Then, you point the column in your Career CSV file that contains the PostID to the Sub-Object Description in your Person Type that establishes the relationship to Post.
When you run this import template, you select ‘Disallow Object Creation’ and ‘Instantly Append new Sub-Objects’. This will transform every row in your CSV file into a new Sub-Object for a Person with a connection to a Post.
Does this work for you?
Yes, the position of the Conditions button has changed. See this part of the nodegoat Guides to learn how to access it: https://nodegoat.net/guides/objectnames . The functionality you are looking for can be found via the tab ‘Nodes’.
Ok! Thanks for this! What happens if you select the relevant type for the column containing the IDs (so for the column ‘ID’ you select ‘People’) and leave the object description empty?
Ok! Can you perhaps share a screenshot of your import template, so we can see how it’s currently configured?
Yes, we see what you mean. We’ll fix it ASAP.
Okay! It seems our last answer was not complete. To filter on objects with a nodegoat ID you should select the relevant type, leave the object description empty and tick both ‘Use data from this column to filter similar Objects.’ and ‘Use data from this column to establish a relation via a pre-existing nodegoat object ID.’. So the first two checkboxes. That should do the trick! Sorry for the inconvenience.
Hi! The best way to do this is to work with some kind of unique identifiers for your objects, so you can link new data from a CSV to objects in nodegoat without having to worry about disambiguation. You can use nodegoat IDs for this (to quickly get a list of these, you get an export of the relevant objects and include the IDs there). You can also enter an ID of your own, or preferably (if possible for your data) a pre-existing identifier like VIAF in an object description (https://nodegoat.net/blog.s/12/linked-data-vs-curation-island). Once you have entered one of these IDs in a column you can use this to find the objects you want to enrich with new sub-objects.
Your CSV would look something like this:
id;dob;dod;pob;pod 234;28-10-1815;12-1-1856;Uhrovec;Modra 631;6-11-1787;7-2-1864;Tršić;Vienna 135;4-1-1785;20-9-1863;Hanau;Berlin
In your Type ‘Person’ you have created an object description that contains the IDs that are also present in the CSV file.
Now you upload the CSV as a source file and you create a new Import Template (like the example above) where you map the column that contains the IDs in the CSV to the object description in your Type ‘Person’ that contains the IDs in nodegoat. If you have used your own IDs you tick the first checkbox ‘Use data from this column to filter similar Objects.’ If you use nodegoat IDs you don’t select an object description and you check the second checkbox ‘Use data from this column to establish a relation via a pre-existing nodegoat object ID.’
If you now run this template, without selecting any of the ‘instant’ options, the import process should find the first object and present you with the new data that you can append or discard. If no object is found, check if it is searchable through ‘quick search’ in your data design.
If you want to run this instantly, you can check the box ‘Disallow Object Creation’ since you will be only appending new data to existing objects. And you check the checkbox ‘Append new Sub-Objects’.
We recommend to first test your setup by running it manually before you run it instantly. It is also good to test your workflow first with a smaller CSV file so you don’t end up with hundreds of objects that have incorrect data.
Does this help you?
Yes, you should be able to import this data without needing to change your data model. Because you are importing relational data, it might be best for you to do the import in multiple steps. First you would import all the editors (based on a file with all the relevant/unique editors, preferable with an ID). Next you can link the publications to these editors while importing by using the IDs that refer to the editors and import this into the relational object description ‘Editor’ in the type ‘Publication’.
Yes, this is certainly possible. What you first need to do is start working with individual index terms. You will need to make a classification in which each object is one index term, this will allow you to create a list of all the terms that are used and use this to explore connecting terms (or make visualisations of networks of terms).
To link these terms to your inscriptions or entries, you create an object description in each type that links to this index term classification. You can allow for multiple index terms to be linked in this object description by checking the first tick-box of the additional options of these object descriptions.
To classify these index terms, you just create one object description in the classification index term that links to another classification (e.g. ‘Kinds of index terms’) which contains the nine categories you mentioned (Proper Names, Kings, Emperors, Geography, Religion, Military terms, Greek and Latin Words, and Selected Topics).
This should allow you to construct a network of interlinked and classified index terms.
Does this help you?
You can now also request a hosted account here: https://nodegoat.net/requestaccount
Just to check: the import module is currently configured to interpret semicolons as column separators, as you probably have seen in the topic you refer to (http://historicalnetworkresearch.org/forums/topic/import-functionality/), is that also the case for your files?
Sure, you can use your own geocoordinates. You can either import them directly as latitude and longitude values in the location references of your sub-objects, or create your own type of locations and use the objects in this type as location references. To test these kind of configurations, we always advise new users to first enter a couple of objects manually into your data design, to get a feel for the way nodegoat works.
Hope this helps!
This should be no problem at all! Two options that you could consider:
 See your type ‘Source’ in a broad perspective so you can include both journal articles as well as journals or references to journals. You could make the nested structure more explicit by adding an additional object description that refers to a classification that you use to specify which kind of source one object is (e.g. ‘article’, ‘journal’, …). For the objects where certain object descriptions are not applicable, you leave them empty. You can then simply filter to get overviews of the sources you would like.
 If you select multiple objects and click the grey ‘multi’ button above the checkboxes, you can change multiple objects by clicking the ‘c’ button. Once you have filtered on a number of objects with a source code, you could change them all at once to enrich them with the missing object descriptions.
The ‘ver’ button allows you to relate objects and its definitions to various sources. They can be used for in-depth source documentation. However, currently you can’t use them in your visualisations and filtering. You can indicate which types you want to use as sources in your project settings.
Does this help you?
Thanks for pointing this out! We’ve fixed a small bug in the export functionality.
You can export all your data per type. Via the ‘Export Settings’ you can specify what data you want to include in your exports and whether you want to include the names of referenced objects or the nodegoat object ID of these objects.
You should be able to achieve this by reducing the time selection to something like 5 or 12 years (and time speed at 1 year) and keep the arrow on the right side of the timeline pressed. This will animate the appearance and disappearance of the posts. Would that suit your needs?
Still, it’s a useful suggestion to play the animation of the movement of the whole timeframe, so we’ll consider adding this functionality.
Okay, we see! By defining a period you tell the visualisation during which period the object is ‘alive’. As long as your time selection touches an object’s date in this period, the object is visualised. So the object only disappears when your time selection falls outside the periods defined for the object (as you rightly illustrate).
This means that when you play the animation, the end of a period does not execute a ‘disappear action’ (since the time selection only grows, it will never go beyond the complete period of your object). A ‘disappear action’ only happens when the time selection is completely beyond (or before) the period of the object. This can be achieved by making the time selection smaller and moving it forward/backward.