Your Attributes strategy should be carefully integrated with your overall AviSys usage strategy. We highly recommend you read Chapter 2, Power and Strategy, Attributes before using this powerful facility. This topic can cover only the highlights.
You can place up to six attributes in any sighting record, describing such things as habitat, behavior, sex, nesting status, heard-only, photographed, egg count, or anything else you choose. Each attribute is a code, consisting of the token / plus one or two characters, in the form /XX. Note that attributes are case sensitive; for example, /g means something entirely different than /G. A provision is made in all report criteria menus to select records based on these Attributes, in combination with the existing date range, Place, species, Checklist, and Key Word criteria.
The figure above is the screen that is available by clicking the Attribute button when you are entering a sighting comment or entering report criteria arguments. You select the Attributes you need from the screen, and they are automatically inserted into the correct location in your comment or report criteria, The Attribute screen supplied with AviSys is a suggested Attribute coding scheme; you can easily modify it to fit your own requirements.
Attribute coding is open ended; you are free to use any coding scheme for any sighting characteristics you choose. AviSys does not “know” the attribute scheme—that is, the program simply resolves the attributes in the sighting record comments, compares the results with the attribute argument in a report criteria, and then selects records accordingly.
Attribute coding has two levels, with the second character being a modifier of the first. A report argument of /W will select only records containing the attributes /W, /WC, /WD, or /W[anything] in their comments. (That means it explicitly rejects all records that don’t have some combination of /W[anything]; it doesn’t care about the second character.) A report argument of /WD, being specific about the second character, will select only records containing /WD, rejecting all others. This feature gives you the power to select sightings from all mountain habitats (/M), for example, or from only mountain deciduous habitats (/MD).
In a report criteria argument there is an implied logical “AND” between adjacent attributes; that is, an argument of /WD/f, selects only records with both /WD and /f (females in deciduous woods). A report criteria can contain up to six attribute arguments.
Thus, a user could request a report with a query as simple as “Show all my sightings at my feeders,” or as complex as “Give me a spreadsheet, by month, from March 1990 through February 1992, of the quantities of nesting, female Hermit Thrushes above 3,000 ft. in the mountain coniferous forests of Sierra County, CA, excluding heard-only records.”
The argument /NO (or /no) is reserved for use in report criteria only. (Don’t put /NO or /no in sighting comments.) The /NO argument is paired with the argument that follows it and modifies it to mean “NOT.” In its simplest use, an argument of /NO/FS would select all records otherwise allowed by the other criteria, but not (would explicitly reject) those with /FS. As a more complex example, the report argument /n/no/WC will cause the report to select only those records with /n, or /n[anything], but will explicitly reject any records with /WC even if they also have a /n attribute.
The most typical use of /NO is to exclude heard-only sightings with the argument /NO/h. You can record your heard-only sightings in AviSys with /h in the comments, but exclude them from reports whenever you wish.
The argument /OR (or /or) is reserved for use in report criteria only. (Don’t put /OR or /or in comments.) The /OR argument is coupled with its preceding and following arguments, modifying them to mean “OR.” For example, the argument /SM/or/FM would mean “Select only records that have either /SM or /FM.”
You can “stack” OR’s. For example, /S/or/FM/or/FS means “Select records containing /S or /FM or /FS.”
You can also combine NO’s, OR’s and (implied) AND’s. /i/S/or/F/no/h means “Select only records that contain /i and (/S or /F) but not /h.” The parentheses in the above argument description are mine, for clarity. I’m sure you have noticed by now that in the unique cases of the /OR and /NO arguments, the lower case /or and /no have exactly the same meanings.
Here are some examples of attribute argument usage, using the scheme pictured in the Attribute entry screen above. Don’t forget that in addition to the attributes, the records could also be selected with species, date range, Place, Key Word, and Checklist criteria. Some of the examples (not necessarily realistic) apply attributes in ways you might not have thought of:
| What you want | How to get it |
|---|---|
| "Select my sightings from any water habitat." | /S/or/F |
| "Select birds I photographed in a nest environment." | /p/n |
| "Select birds I actually saw in courting behavior." | /NO/h/c |
| "Select my sightings of mature birds constructing nests in fresh water shore or marsh habitat." | /NO/i/nc/FS/or/FM |
| "Select the birds that used my feeder #1 " | /E1 |
Imagine a bird photographer who keeps accurate records in AviSys, uses Attributes, and also puts slide file location numbers in her comments. She gets a call from an agency: “We need pictures of birds brooding on nests. What have you got?” /nb/p Zap! “Well, I have bluebirds and orioles and Osprey and hummingbirds and......”
An ornithologist might use Attributes to isolate sighting data by geographic coordinates (or grids) for a census study. A census report criteria argument of /A/84/OR/85 would restrict the selected records to those from grids A-84 or A-85, for example. Here’s an example of ambiguity in verbal syntax. When putting that argument together you would probably verbalize it as “Give me the sightings from A-84 and A-85.” Everybody but AviSys (or a logician) would know what you meant. You really meant “Give me the sightings from A-84 or A-85.” There’s no such thing as a sighting at A-84 and A-85; a bird can’t be in two places at the same time.
Sightings from a larger area could be accessed with /A/OR/B/84/OR/85, which will select sightings from the square composed of the grids A-84, A-85, B-84, B-85. /A will get the entire “column” A-1..n. /42 will get the entire “row” A..Z-42.
If you get really serious with Attributes, you can employ them as a useful shorthand in your comments. Rather than entering them all together, you could do something like this: 6 /f seen /nb in /MC at /L3 , which would mean “Six females seen brooding on nests in mountain coniferous forest above 3,000 ft. elevation.”
AviSys will check your argument entries for syntactical correctness. If you try to do something logically impossible, such as /NO/OR/n, it will give you an error message. (A valid attribute must follow /NO; a /OR must have a valid attribute on each side of it.) It can’t, however, check to see if your argument really says what you meant it to say. That’s your responsibility. AviSys can’t read your mind—it just reads your arguments.
The lower case arguments /no and /or function identically to the upper case /NO and /OR.
Attributes (and arguments) can contain the following characters:
0..9, a..z, A..Z, : ; < > = ? @ [ ] ^ _ ‘ \
(In anticipation of possible future AviSys enhancements, you should reserve the attributes /=, /[, /], /<, and /> from any coding scheme you develop. You should also avoid the use of \ . It’s just too easy to confuse with / .) The Attribute /? is reserved for identifying the records that are not true lifers when multiple records of a life species are recorded on the same day. See Real Lifers in Chapter 1. The relative sequence of Attributes in comments is unimportant. AviSys will always find the correct ones for comparison.
Ah, yes, I’ve been so focused on explaining those codes and how they work that I forgot to emphasize one important point: You don’t have to mess around with the codes themselves. Take a look at the Attribute window, from which you select the codes to be placed in your comments and report criteria. You don’t select the codes, you select the descriptions—which are plain English.
You might be considering using Attributes for dual birders, such as /g for Gary, and /k for Karen. With that scheme, it would be easy to separate Gary’s and Karen’s records to ask “What has Gary seen?” and “What has Karen seen?” However, in database parlance, you can’t join Gary’s and Karen’s records to ask “What have we both seen?” or to ask “What has Gary seen that Karen hasn’t?” Likewise, using /b for “Both saw it” will not reliably allow you to ask “What have we both seen?” unless you really want to know what birds you have both seen and recorded in the same sighting record.
The suggested coding scheme is provided in the form of a window which is available when entering comments or criteria arguments.
You can modify the Attributes Table to match your own scheme by clicking the Add, Edit or Delete buttons. When adding Attributes, the dialog suggests the correct format, such as:
S SALT WATER
S R rocky shore
S S sandy shore
The new attribute is added after the currently highlighted one.
AviSys takes care of the indenting of the two-letter “sub-codes” on the screen. The "top level" form, X XXXX, shows up bold on the screen. There is a 14 character limit to the length of the description. You can have up to 100 Attributes in the table. If you need the room, remove the notation “CRITERIA ONLY” which is placed there just as a reminder. You could also remove the NOT and OR entries, but you would have to enter those manually in criteria using the Manual button.
The Attributes table can be reached at any time via the File menu.
One of the Attribute codes is /t “Trip Record” which means “This record defines a trip.” If you select one sighting record from each trip, one which requires little other comment space, and enter a comment something like “/t Yosemite trip with Harry 3/20-3/24/92”, you have made an entry in your trip log. (You didn’t know you had a trip log, did you?) To record detailed information about the trip, attach a Field Note to the record. While the record is a real one, recording a sighting from the trip, it also serves as a “token” record for your Trip Log.
Having created one such record for each birding trip, you can do a Sighting File Listing with an attribute argument of /t to list all your “trips.” You can even add a Key Word argument like “Harry” to list only those trips with Harry, and/or a Place criteria, like “Colorado” to list your Colorado trips, and/or a date criteria to list trips in a range of dates. You could ask “Show all my trips in Ohio with Patsy from April 15, 1990 through June 3, 1991.” Each token record has a brief description of the trip (the comment) and possibly comprehensive details in an attached Field Note.
The trips can be listed in date sequence (a chronology of trips) or in Place sequence (where all trips to the same Place are listed together). You could even periodically print out the listing as a hard copy trip log. To list all your sighting records from a given trip, simply use the date range, and possibly the Place, from the comment in the token trip record as the criteria in a Sighting File Listing. (The Place is not really necessary unless you had two trips on the same day or range of days.)
In addition to the 99 Attributes available in the main Attributes table, you can add up to 5,000 additional Attributes in a special Attribute list which pops up when you click the List button. You can select multiple Attributes from the list, and when you click Return those Attributes are added to any you might have already selected from the main table. When adding to the list, it is your responsibility to ensure that you are not creating duplicates -- although there might be good reason to do so because identical Attributes might have different meanings in various contexts. The list maintains the Attributes in alphabetic order by description.