DBRoot
|
|__ Artefact Record
| |
| |__ Images
| | |___ *.jpg etc.
| |
| |__ Documents
| | |___ *.doc, .xls etc.
| |
| |___artefact.record (text file)
|
|___ DBPrimaryIndex.index (text file)
|___ DBPrimaryIndex.schema (text file)
|
|___ DB secondary indices & schemas
RecordTitle is Mineral Specimen Details
========================
Entry No:
ARC-99-000021
================================================================================
Species:
Minerals = Zeunerite
Rutherfordine
Zippeite
Chalcopyrite
.var Blister Copper
Quartz
.var Agate
.colour White
Opal
.var Common Opal
.colour Transparent
Matrix = Quartz
================================================================================
Location:
South Terras Mine
St Stephen in Brannel
St Austell
Cornwall, UK
Grid Reference = SW 935 524
GPS Coordinates = 50.33444,-4.90194
================================================================================
Collection Data:
collected by = Self collected
Collection Date = 1979
================================================================================
Acquisition Data:
Acquired Date = 14 Jul 1998
From = Self collected
Field Ref No = F20180623-STUM-001
Temp Ref No = TMP 0 0099
================================================================================
Analytical Data:
Commentary = 4 species
Zeunerite = { Colour and crystal form are typical for this location.
}
.date 14 Aug 2018
.Report AN-201808-14-01
.Ref_Number ZZ8088
Zippeite = { Colour is diagnostic for this location
}
.date 14 Aug 2018
.Report AN-201808-14-02
.Ref_Number ZZ9099
Chalcopyrite = { Well characterised at this location.
Deep indigo tarnish on old surfaces.
}
Rutherfordine = { Tentative ID.
}
.Reasons Visual ID only
================================================================================
Accession Data:
Accession No = ZZ9099
Accession Date = 21 Sept 2000
Sub-collection = Main
Image Data:
Mugshot = img0001.jpg
Images = img0001.jpg
.Title Whole Specimen
.TakenDate 11 Nov 2018
.Width 11.5mm
.camera Fuji FinePix L55
img0002.jpg
.Title Zeunerite & Chalcopyrite
.TakenDate 11 Nov 2018
.FOV 1.1mm
.Camera CL 1600 USB MicroCam
===== DB System Info ===========================================================
RecordType is 1
LastSavedTime is 13/11/2018 13:18:37
(Previous Version was 13/11/2018 12:12:47 )
================================================================================
The format is:This is sounding more and more like a RetroB challenge if where you are feels that comfortable.
|Unique | |Accession| |other stuff| |Collection | |Analysis | |Field |
|number | |reference| |name | |reference| |reference |
ARC00796 M00796 Minerals
ARC00797 M00797 Minerals F199709144
ARC00798 M00798 Minerals
ARC00799 M00799 Minerals
ARC00800 M00800 Minerals A19990301 F199903261
ARC00801 M00801 Minerals F199903261
ARC00802 M00802 Minerals F199903261
Schema:
Database = Mineral DB
Filename = DBPrimaryIndex.schema
Target = DBPrimaryIndex.index
Size = 148
; Record size of index in bytes - will be padded to fit.
; - the index *is* a random access file, after all.
;
; Type:
; 0 = String
; 1 = Boolean String 'True'/'False'
; 2 = Long Integer
; 98 = Deletion Flag ('D' / 'H' / 'X' / ' ') (= Deleted / Hidden / Expunged / normal)
; 99 = String / Autonumber
; Prefix = (string)
; Body = (picture)
; Suffix = (string)
; Datestamp = null or (picture)
; Class:
; [none] = Default index type (plain secondary index)
; PK = Primary Key (auto numbered sequence number)
; SK = Secondary Key (usually the fully formatted version of the PK,
; which should be an integer
; FG = File Group - by which record cards are arranged on disk
; (directory structure)
; SG = Secondary File Group - by which records without an FG
; value are grouped on disk.
;
Field:
; DELETION flag (Boolean)
Name = Deleted
LPos = 1
Width = 1
Type = 98
Class =
Path = NONE
XPath =
Field:
; Sequential DB entry number - a SUBSET of the ARC Number
; SeqNo
Name = SeqNo
LPos = 5
Width = 6
Type = 99
Class = PK
Path = Main.idx
XPath =
Field:
; Sequential entry number
; ARCNo
Name = ARCNo
LPos = 2
Width = 15
Type = 02
Class = SK
Path = Main.idx
XPath =
Prefix = ARC
Body = 9999999
Suffix = 0
Timestamp = 0
; System timestamp (19 characters for 'Now()' )
Field:
; Accession Number is the specimen reference for
; all accessioned specimens.
; AccNo
Name = Accession No.
LPos = 17
Width = 12
Type = 0
Class = FG
Path = AccNo.idx
XPath= Acquiry Reference
Field:
; Field Number or other reference to material that
; hasn't been accessioned as collection specimens.
; AcqRef
Name = Acqusition Reference
LPos = 29
Width = 24
Type = 0
Class = SG
Path = AcqRef.idx
XPath =
Field:
; Sub Collection Name
; SubColl
Name = SubCollection Name
LPos = 53
Width = 24
Type = 0
Class =
Path = NONE
XPath =
Field:
; Analytical Reference
; Aref
Name = Analytical Reference
LPos = 77
Width = 12
Type = 0
Class =
Path = NONE
XPath =
Field:
; Field Reference
; FRef
Name = Field Reference
LPos = 89
Width = 12
Type = 0
Class =
Path = NONE
XPath =
End:
right now, with VB, I'm stuck with the ASCII character set,
EXTERNAL PREPROCESSOR
This module executes external preprocessors. These preprocessors are standalone executable programs that read the source program and create another file that is read and processed by the ScriptBasic interpreter. If an external preprocessor is used the source file is usually not BASIC but rather some other language, usually a BASIC like language, which is extended some way and the preprocessor creates the pure ScriptBasic conformant BASIC program. The sample preprocessor supplied with ScriptBasic is the HEB (HTML Embedded BASIC) preprocessor that reads HTML embedded BASIC code and creates BASIC program. This HEB source file is a kind of HTML with embedded program fragments, which you may be familiar with in case you program PHP or Microsoft BASIC ASP pages. The HEB preprocessor itself is written in BASIC and is executed by ScriptBasic. Thus when a HEB "language" is executed by ScriptBasic it starts a separate instance of the interpreter and executes the HEB preprocessor on the source file. Of course the HEB preprocessor could be implemented in any language that can be compiled or some way executed on the target machine. Actually the very first version of the HEB preprocessor was written in Perl so when it was first tested the ScriptBasic interpreter started a Perl interpreter before reading the generated BASIC code.
Note that the HEB preprocessor provided in the ScriptBasic package is an example implementation and lacks many features. It can, for example, be fooled by putting a %> characters into a BASIC string constant.
I only wish that VB6 wasn't such a stickler for _stdcall in DLL's, it's the main reason I left it many years ago for Delphi/Lazarus....
@Alysson -
I took a deep dive into your code, it's really nice!!
Great Job!
I only wish that VB6 wasn't such a stickler for _stdcall in DLL's, it's the main reason I left it many years ago for Delphi/Lazarus....
AIR.
AIR has already offered a promising solution for the back end text DB. Can you share what you have or envisioned for a UI?
Peter's HEB SB pre processor is sounding better by the post. 8)
One idea is use SB associtive arrays as a form of of readable DB data that has immediate functionality.Code: ScriptBasic
COLLECTIONDATA{"collected_by"} = "Alysson" COLLECTIONDATA{"collected_date"} = NOW
This embedded in a preproessor HEB like format gives you a DB and web page definition in one file / record.
The associative array definitions is the data along with the HEB definition that would display it all as a record.
All well and good, but you need to get the data from the file first. So how would you approach that?
"db.json" f:slurp json>
( swap "%s : %s" s:strfmt . cr ) m:each drop
I'm going to let Alysson chew on this for awhile before I refine the concept any further.
Required Format?
The primary requirement is that the textual data must be kept entirely in human-readable digital format (i.e. text files), thus, software-proofing the data. That includes indices and data (images and other media excepted). The artefact record is, in fact, a single document. Even EXIF-type metadata on media files is maintained in separate text documents alongside the media files.
The associative array definitions in a text file aren't readable?
Too bad using JSON for data is not allowed. I would have used 8th for this challenge. I think JSON is readable enough and if needed nicely formatted presentation of the data needs just a few lines of code.
In 8th, only few lines of code is needed to read JSON data from file to map. Following code reads data from the file and outputs keys and data from the resulting map:Code: [Select]"db.json" f:slurp json>
( swap "%s : %s" s:strfmt . cr ) m:each drop
The question becomes is the goal to maintain a broken design or make it run under today's standards?
The associative array definitions in a text file aren't readable? The web site definitions and 'meta data' can reside in the included template file. All run by the pre-processor threaded.
I find myself really mourning the lack of Type (or other data structure) definitions in SB (or have I missed something here??)
I'm curious to see what you mean. I've attached a json version of the yaml data file I used....
var db
: load
"testI.json" f:slurp json> db ! ;
: number-or-string
. cr ;
defer: iter
: array
cr ( nip space space space space dup >kind iter cr ) a:each drop ;
: map
cr ( swap space space . ": " . dup >kind iter ) m:each drop ;
: iterator
[ ' number-or-string , ' noop , ' noop , ' number-or-string , ' array , ' map ] swap
caseof ;
' iterator w:is iter
: disp
db @ ( swap . ": " . dup >kind iterator ) m:each drop ;
load disp
bye
QuoteI find myself really mourning the lack of Type (or other data structure) definitions in SB (or have I missed something here??)
SB supports LONG, REAL, (binary) STRING, ARRAY and UNDEF. Arrays can be index or associative or a combination of both with no practical limitation. A great way to build complex structures.
You can pass an UNDEF variable as an argument to a function/sub and return a complex array structure in the same variable name.
I'm curious to see what you mean. I've attached a json version of the yaml data file I used....
Here is some demo code to read JSON file into map and display the content on screen...
Does 8th support maintaining the order of the data when you output it?
Does 8th support maintaining the order of the data when you output it?
8th seems to store the data in different order, so iterating map directly changes order of the data outputted. I guess I would need to iterate the map keys in correct order myself.
Associative arrays seems the only way I know of taming these hash lists.
In SB it's about creating freeform structures that can contain any of the data types SB supports. LBOUND/UBOUND are key functions to keep it all together.
No matter how complex your array structure gets, you can iterate though it using standard indexing methods.
Anyway, we've derailed the original topic enough
How about you getting us going on something else to keep things moving?