|VUG Home Page NIST Web Metrics Technical Overview FLUD Overview FLUD Results|
The parse file is a highly stylized rendition of the original logfile.
Its intended purpose is to serve as input to other automated
processes, such as analyzers and visualizers. Instead of
processing the logfile directly, they can invoke the parser
to perform low-level syntax checking. The resulting
parse file can then be easily analyzed for higher-level
purposes, such as statistical summaries and the like.
Each logfile record is essentially a sequence of fields. Each field has a name and a value (e.g. time_zone=7). In the logfile, the field name may be implicit. Each record of the parse file describes one field of the logfile. The parsed record format is:
field-name "=>" value-type "/" valueSome additional derived fields for the time value are also written. Finally, the parsed file contains a separator (a line of dashes) between the fields of one logfile record and the next. An example should help make this clear. The following two input records:
qhead 2000/01/18-13:33:55.11 Questionnaire_22 qrec Q_006 "about once a week"generate the following chunk of parsed file:
--------------------------- rectype => L / qhead time => T / 2000/01/18-13:33:55.11 days => I / 51561 secs => N / 48835.11 questionnaireID => L / Questionnaire_22 --------------------------- rectype => L / qrec questionID => L / Q_006 response => A / "about once a week"Note that the original time field generates a days field and a secs field. The former is the Modified Julian Date, and the latter is the number of seconds within the current day. This makes it easier to calculate time intervals. The value-type field indicates the syntax of the value itself following the slash. See the table of parse file value-types for details. For detailed semantics, see the FLUD specification.
The standard suffix is "parse". Full file name is SessionName/SessionName.parse.
This file is essentially a pretty-print version of the logfile.
Indentation and color are used to clarify the file structure.
Thus, this file is primarily oriented towards human review.
If syntax errors are found, an error message will be inserted
in the HTML file.
The standard suffix is "html". Full file name is SessionName/SessionName.html.
|Userpath files for VisVIP||
These files are designed as input to VisVIP, which presents a 3D
visualization of users' navigation of a website. Each task within
the session generates a separate file (see Example 1 in the Operation page); thus,
each file represents the web pages visited by the subject during a
single task, and the length of time spent on each page. Each record
in the file has two fields: a unique nickname for the URL
visited and the number of seconds spent there by the user.
The standard suffix is "up". The naming convention for these files is
SessionName/TaskType-TaskCount.up.The TaskType is taken from the taskhead record in the logfile, and the TaskCount is simply a sequential count of the executed tasks in the logfile (prefaced by "t") to ensure a unique name if the same task is attempted twice. I.e. TaskType identifies the type of task attempted and TaskCount keeps track of the number of task instances. For example, if a subject tries to complete a "buy_shirt" task, then goes on to a "inspect_shoes" task, and then goes back to re-execute the buy_shirt task, the generated files would be named something like:
When generating userpath files ("u+" parameter), the $WEBLOG_DATA/website/webstruct subdirectory must contain an "url2nn.dat" file, to provide a mapping from the full URL of a page to a nickname. See Example 2 in Operation for more details.
|Error messages and warnings||Finally, whenever syntax errors or other anomalous conditions are encountered, an error message or warning will be written to the standard error device (STDERR). Syntax errors are also written to the HTML file.|
Page last modified: 15 May 2002
National Institute of Standards and Technology (NIST)