|
VARIOUS H3 HEADER FIELDS (COLLECTING, INX, ...)
attached
| What should the field look like? |
Syntax: [attached:xxx]
|
| |
| What does the field contain? |
An indication of an attachment to an issue. For instance toys or mini-booklets.
Only specified in some of the DBI files, if the indexer thinks it's useful to list it. |
| |
| Which log messages are related to this field? |
|
None.
|
| |
| Which CSV field(s) use this field? |
Table inducks_issue, field attached
|
| |
|
collecting
| What should the field look like? |
Syntax: [collecting:xx(Y/Z),xx(Y/Z)]
|
| |
| What does the field contain? |
One or more issue codes from comics that are exactly reprinted in this issue. Or in fact collected, for instance under a new cover.
The contents (stories) of those issues are not repeated in the input file.
Note that the collected issues can be from a different country, but everything will be the same, including the titles. We use this for Portuguese collections of Brazilian comics.
The "collecting" field has the following syntax:
[collecting:A] or[collecting:A(-)] or[collecting:A(P)] or[collecting:A(P/X)] or- combinations of the above, separated by commas:
[collecting:A(P/X),B(Q/Y),C(R)]
The second option [collecting:A(-)] indicates that issue A is collected, but its full contents is listed explicitly.
So this is just informational, no automatic content-copying is done.
In the above, the letters have the following meaning:
- A = an issue code of a collectee, with or without country (like DE1987-09 or nl/DE1987-09)
- P = a lower-case letter indicating the position of the collectee in the collector
- X = one or more lower-case letters, separated with commas, indicating which items from the collectee are NOT in the collector.
The "collector" is the issue that collects the contents of one or more other issues.
A "collectee" is an issue that has been collected in a "collector".
I think I can further explain this by giving an example.
The Dutch issue file contains, for instance:
AO 1 h3 [inx:RKo,ANi] [collecting:SG 32,SG 30]
AO 1a HC AO 1 1 c DD
(and nothing else for that issue)
In this case, Dizni produces the following (a bit shortened for readability):
AO 1 h3 [inx:RKo,ANi] [collecting:SG 32,SG 30]
AO 1a HC AO 1 1 c DD
AO 1ba HC SG 32 1 c MdJ US
AO 1bb I AT 320-B 24 FBa US De vaas van pandora
AO 1bc W DAD 41-04 6 BGy DA Als hardloopster
AO 1bd W WDC 370-02 2 PAl CD
AO 1ca HC SG 30 1 c MdJ US
AO 1cb I AT 331-A 20 FBa US De verdwenen Eiffeltoren
AO 1cc D 6984 10 VR DD Aan de bal [xapp:DA,DD]
AO 1cd W WDC 379-02 2 PAl CD
So it copied the complete contents of the indicated issues. Dizni invented its own sequence letters
(for instance "ba"-"bd" for the items from the first collectee).
If you don't want to have Dizni generate sequence letters, you can put it in the collecting field as follows (using "s" and "t"):
AO 1 h3 [inx:RKo,ANi] [collecting:SG 32(s),SG 30(t)]
AO 1a HC AO 1 1 c DD
In this case, Dizni produces the following:
AO 1 h3 [inx:RKo,ANi] [collecting:SG 32(s),SG 30(t)]
AO 1a HC AO 1 1 c DD
AO 1sa HC SG 32 1 c MdJ US
AO 1sb I AT 320-B 24 FBa US De vaas van pandora
AO 1sc W DAD 41-04 6 BGy DA Als hardloopster
AO 1sd W WDC 370-02 2 PAl CD
AO 1ta HC SG 30 1 c MdJ US
AO 1tb I AT 331-A 20 FBa US De verdwenen Eiffeltoren
AO 1tc D 6984 10 VR DD Aan de bal [xapp:DA,DD]
AO 1td W WDC 379-02 2 PAl CD
Note the entry codes.
Finally, sometimes an issue is reprinted/reused, except for the cover. Using the above example, we can indicate this as follows:
AO 1 h3 [inx:RKo,ANi] [collecting:SG 32(s/a),SG 30(t/a)]
AO 1a HC AO 1 1 c DD
In this case, Dizni produces the following:
AO 1 [inx:RKo,ANi] [collecting:SG 32(s),SG 30(t)]
AO 1a HC AO 1 1 c DD
AO 1sb I AT 320-B 24 FBa US De vaas van pandora
AO 1sc W DAD 41-04 6 BGy DA Als hardloopster
AO 1sd W WDC 370-02 2 PAl CD
AO 1tb I AT 331-A 20 FBa US De verdwenen Eiffeltoren
AO 1tc D 6984 10 VR DD Aan de bal [xapp:DA,DD]
AO 1td W WDC 379-02 2 PAl CD
Note that the entries "sa" and "ta" are missing now.
The "collecting" field is intended to make life easier for indexers, by allowing a reference, instead of the same data twice, in the input files.
The rest of Inducks does not even notice how the data was entered. |
| |
| Which log messages are related to this field? |
Log1 (serious)
180: More than 26 issues collecting; use explicit letters
181: Duplicate position in collecting field: ... (already used ...)
705: Contents of (...), collected in (.../...), not found
|
| |
| Which CSV field(s) use this field? |
Table inducks_issuecollecting, field collectedissuecode
|
| |
|
equiv
| What should the field look like? |
Syntax: [equiv:xx/xxxx(YY),xx/xxxx(YY)]
|
| |
| What does the field contain? |
A list of issues (from various other countries) that have exactly or nearly the same contents.
One issue is listed in the form "country/issue code", for instance "nl/DD1952-01".
See also entrycode.
The code behind the issue (YY) can contain the following letters:
- g = the gags in the issues may differ
- c = the covers of the issues may differ
- p = only part of this issue is equivalent to the other issues
|
| |
| Which log messages are related to this field? |
Log2 (error)
225: Issue ... has equiv but is not in equivs file (equiv data <...>)
226: Equiv <...> contains data that is not (or differently) in equivs file <...>
|
| |
| Which CSV field(s) use this field? |
|
|
| |
| How is the data used in the rest of Inducks? |
The field is only used to give hints (in the form of log messages) to the maintainer of the file equivs.dbx.
This file contains all equivs of all countries, and is used to detect differences (i.e. errors) in the indexes of the equivalent issues. |
| |
|
inx
| What should the field look like? |
Syntax: [inx:xx(xx),xx(xx)] or [inx:-,xx(xx)]
|
| |
| What does the field contain? |
The indexer of an Issue.
This can be (and often is) more than one person.
An indexer has produced or checked all of the data in the index against the actual issue (or a reliable reproduction of the entire issue, for example newspaper microfilms).
If an issue is indexed, use [inx:-].
If an issue is only partially indexed, use [inx:-,xx(xx)]. |
| |
| Which checks are done? |
| This field should not be empty. If the indexer is unknown, a '?' should be used (this should in fact never happen...). |
| |
| Which log messages are related to this field? |
Log1 (serious)
201: no indexer specified, use inx:- or inx:?
287: Field ... contains an item (...) more than once
- Every name or abbreviation should occur only once.
Log3 (info)
293: ... <...> is an ambiguous name
294: ... <...> should be indicated as <...>
298: ... <...> should be spelled as <...>
- The field is almost right: some spaces or capital letters differ.
|
| |
| Which CSV field(s) use this field? |
Table inducks_issue, field fullyindexed
Table inducks_issuejob, field doubt
Table inducks_issuejob, field inxtransletcol
Table inducks_issuejob, field issuejobcomment
Table inducks_issuejob, field personcode
Table inducks_person, field numberofindexedissues
|
| |
|
issdate
| What should the field look like? |
Syntax: [issdate:yyyy-mm-dd(xx),yyyy-mm-dd(xx)]
|
| |
| What does the field contain? |
The (cover) date of an Issue.
The field can contain multiple dates, each followed by a comment. For example:
[issdate:1980-01-01,2000-03-03(reprint)]
or
[issdate:1980-01-01(cover),1980-01-03(indicia)]
Make sure the oldest date is always the first in the list!
(Note that this is the only date field where multiple dates are allowed.) |
| |
| Which checks are done? |
Standard date field checks:
The field always has the (international standard) format "yyyy-mm-dd".
If the day is unknown, the field has no "-dd" ("yyyy-mm"). If the month
is unknown too, the date is simply a 4-digit year.
If only the quarter of the year is known, the date format is "yyyy-Qx" where x is 1,
2, 3, or 4. For instance "1998-Q3" = 3rd quarter of 1998.
A date field can be followed by a '?'.
If a date contains a letter 'y', 'm', or 'd', the rest of the date, starting with this letter, is ignored.
This allows dates like "1978-mm-dd" and "1978-03-dd". (This feature was added to make the input more readable.
Use it with care!)
Note that the full 4-digit year is mentioned in the date.
The checking on real dates is not done completely, for instance February 29th is allowed in all years.
|
The field should never be empty (it must be at least '?'). |
| |
| Which log messages are related to this field? |
Log1 (serious)
271: ... <...> format should be yyyy-mm-dd
272: ... <...> non-digit
273: ... <...> wrong month
274a: ... <...> wrong day of month (31)
274b: ... <...> wrong day of month (30)
276: ... <...> wrong format
277: ... <...> wrong day
Log3 (info)
227: issdate should have a value (or '?' if fully unknown)
|
| |
| Which CSV field(s) use this field? |
Table inducks_issue, field filledoldestdate
Table inducks_issue, field oldestdate
Table inducks_issuedate, field date
Table inducks_issuedate, field doubt
Table inducks_issuedate, field kindofdate
|
| |
| How is the data used in the rest of Inducks? |
| See pubdate. |
| |
|
issuecode
| What should the field look like? |
Syntax: fixed position, or [entrycode:xx] (yes, entrycode)
|
| |
| What does the field contain? |
| A code indicating the issue. |
| |
| Which checks are done? |
The codes in a DBI file should be in exact alphabetical order.
An h3 issuecode should match (i.e. start with) the code of the corresponding h2 header, the issuerangecode.
Or, if there is no h2 header, the code of the corresponding h1 header, the publicationcode.
|
| |
| Which log messages are related to this field? |
Log1 (serious)
220: Lines are not properly sorted (... should be after ...)
221: Identical entrycodes
- Dizni tries to repair this error by making up a unique code.
|
| |
| Which CSV field(s) use this field? |
Table inducks_equiv, field issuecode
Table inducks_issue, field issuecode
Table inducks_issue, field issuenumber
Table inducks_issuecollecting, field collectingissuecode
Table inducks_issuedate, field issuecode
Table inducks_issuejob, field issuecode
Table inducks_issueprice, field issuecode
Table inducks_issueurl, field issuecode
Table inducks_log, field logkey
Table inducks_publishingjob, field issuecode
Table inducks_story, field issuecodeofstoryitem
Table induckspriv_issue, field issuecode
|
| |
|
translating
| What should the field look like? |
Syntax: [translating:xx]
|
| |
| What does the field contain? |
A bit like collecting, but in a different language.
The index of the referred issue should have story titles in 2 languages, separated by a tilde (~).
This field was designed (in 2012) for the Belgian issue index.
It is not recommended to use it anywhere else! |
| |
| Which log messages are related to this field? |
|
None.
|
| |
| Which CSV field(s) use this field? |
|
|
| |
|
|
|
|
