Ok, we've got our Image Load File (ILF) setup correctly; how do we setup the images themselves?
(From our ILF:
201,Box001,00\01\exh001.001.tif,Y,,,
202,Box001,00\01\exh001.002.tif,,,,
203,Box001,00\02\exh002.001.tif,Y,,,
204,Box001,00\03\exh003.001.tif,Y,,,
205,Box001,00\03\exh003.002.tif,,,,
206,Box001,00\03\exh003.003.jpg,,,,
207,Box001,00\03\exh003.004.tif,,,,
)
We need to copy our image files into our case like this:
<drive letter>:\vs_data\CaseID\Image\Box001\00\01\exh001.001.tif
etc.
We should have received a disk with a directory named "00" on it. In that directory should be another directory named "01", through "03". And within each of these directories should be files named (for instance) exh001.001.tif.
If we are lucky the "00" directory is within a directory named "Box001". If so, we simply copy the Box001 directory into the Image directory within our caseID directory.
If we just have the "00" directory, then we have to create a new directory called "Box001" within the Image directory within our caseID directory. The copy the "00" directory into this new directory.
And we are all done.
chuck
http://www.visionarylegal.com/
Tuesday, April 12, 2011
Monday, April 11, 2011
What about this Image Load File Process, Part One
"We have several bankers boxes of documents that need to be added to our case!"
"I just got a cd (or even worse, a dvd) from the opposing counsel with tens of thousands of images."
"We were just called in to take over from a previous firm and I found a drive full of images."
Whatever the situation, now you have to try to get all these documents into your case and go to trial.
What you need is an Image Load File.
An Image Load File allows you to populate your document database in an automated process, rather than adding one document at a time.
There are many different formats; however you will find that many so-called "image load files", are not actually Image Load Files. Rather they are document load files or, even worse, a simple directory structure.
I am going to be discussing the most basic Image Load File (ILF), called an Opticon-type load file. Ever scan shop should be able to produce this format.
First, let's take a look at a sample file.
201,Box001,00\01\exh001.001.tif,Y,,,
202,Box001,00\01\exh001.002.tif,,,,
203,Box001,00\02\exh002.001.tif,Y,,,
204,Box001,00\03\exh003.001.tif,Y,,,
205,Box001,00\03\exh003.002.tif,,,,
206,Box001,00\03\exh003.003.jpg,,,,
207,Box001,00\03\exh003.004.tif,,,,
Let's pull this apart and understand what is going on here.
Since we are loading a database, each line in this file represents one record in the Image Database. Therefore there needs to be one line (record) for EVERY page of EVERY document. Visionary needs to be able to find and display the image file (in this case, the .tif or .jpg files) for each page of each document.
We can see that there seems to be four fields in each record. Each field is separated by a comma. (This is generically called a CSV file, Comma Separated Values file. Obviously, your data CANNOT contain any commas.) In the case of an ILF, there is NEVER a need for the data to contain commas.
Database Key Field or Page ID value
The first field (201) must be unique within each case. You cannot have two lines with "205" in the first field. This is the "key" that the database uses to find a specific record or image. Since it is the key field, every database will have specific constraints on it.
For Visionary, these are the constraints:
Volume Label
The second field (Box001) is a holdover from the days when hard drives were not large enough to hold all the data, and the CD Label was used to find the correct optical disk to use. Now it refers to the directory within \vs_data\CaseID\Image directory. It, obviously, does not need to be unique and will most likely change with each scan job iteration. There can be multiple different entries in this field, even within one ILF.
Path To and Image File Name
The third field (00\01\exh001.001.tif) is where the actual image is located in relation to the Volume Label. It does NOT contain drive letter information, such as "c:\". So within the directory with the Volume Label name, there should be a directory named "00" and within that a directory named "01" and then a file named "exh001.001.tif"
First Page Indicator
The fourth field is a "Y" if this record is the first page of a document, otherwise it is left empty.
There are no other fields.
chuck
VisionaryLegal.com
"I just got a cd (or even worse, a dvd) from the opposing counsel with tens of thousands of images."
"We were just called in to take over from a previous firm and I found a drive full of images."
Whatever the situation, now you have to try to get all these documents into your case and go to trial.
What you need is an Image Load File.
An Image Load File allows you to populate your document database in an automated process, rather than adding one document at a time.
There are many different formats; however you will find that many so-called "image load files", are not actually Image Load Files. Rather they are document load files or, even worse, a simple directory structure.
I am going to be discussing the most basic Image Load File (ILF), called an Opticon-type load file. Ever scan shop should be able to produce this format.
First, let's take a look at a sample file.
201,Box001,00\01\exh001.001.tif,Y,,,
202,Box001,00\01\exh001.002.tif,,,,
203,Box001,00\02\exh002.001.tif,Y,,,
204,Box001,00\03\exh003.001.tif,Y,,,
205,Box001,00\03\exh003.002.tif,,,,
206,Box001,00\03\exh003.003.jpg,,,,
207,Box001,00\03\exh003.004.tif,,,,
Let's pull this apart and understand what is going on here.
Since we are loading a database, each line in this file represents one record in the Image Database. Therefore there needs to be one line (record) for EVERY page of EVERY document. Visionary needs to be able to find and display the image file (in this case, the .tif or .jpg files) for each page of each document.
We can see that there seems to be four fields in each record. Each field is separated by a comma. (This is generically called a CSV file, Comma Separated Values file. Obviously, your data CANNOT contain any commas.) In the case of an ILF, there is NEVER a need for the data to contain commas.
Database Key Field or Page ID value
The first field (201) must be unique within each case. You cannot have two lines with "205" in the first field. This is the "key" that the database uses to find a specific record or image. Since it is the key field, every database will have specific constraints on it.
For Visionary, these are the constraints:
- It must be less than 21 characters
- It can only consist of letters
- Lower, Mixed and Upper are treated the same; exhibit, Exhibit and EXHIBIT are the same.
- Digits 0 through 9
- Leading zero's are stripped
- and these characters "+", ".", "-", and "_"
Volume Label
The second field (Box001) is a holdover from the days when hard drives were not large enough to hold all the data, and the CD Label was used to find the correct optical disk to use. Now it refers to the directory within \vs_data\CaseID\Image directory. It, obviously, does not need to be unique and will most likely change with each scan job iteration. There can be multiple different entries in this field, even within one ILF.
Path To and Image File Name
The third field (00\01\exh001.001.tif) is where the actual image is located in relation to the Volume Label. It does NOT contain drive letter information, such as "c:\". So within the directory with the Volume Label name, there should be a directory named "00" and within that a directory named "01" and then a file named "exh001.001.tif"
First Page Indicator
The fourth field is a "Y" if this record is the first page of a document, otherwise it is left empty.
There are no other fields.
chuck
VisionaryLegal.com
Friday, April 8, 2011
Use of the Visionary 8 Professional QuickSync Feature
The QuickSync feature in Visionary 8 Professional allows the creation of text-to-video synchronized depositions.
First, what do you need?
Visionary 8 Professional, installed and registered, obviously.
The Visionary Auto-Syncer. This ONLY needs to be installed. You cannot register it if you have Visionary 8 Professional
The Visionary Auto-Syncer. This ONLY needs to be installed. You cannot register it if you have Visionary 8 Professional
An electronic text copy of the transcript. This should be an ASCII text file, in the Amicus format.
The media files in MPEG-1 format, VCD standard. (Your videographer should be providing you with these files. If they are providing you with anything else except VCD standard mpeg-1 files, they are doing you a tremendous dis-service.)
With those prerequisites set, we are ready to start.
Launch Visionary and open your case.
Use the File, Import, Transcript option.
If you do not see your deponent listed, in the Visionary Shortcut bar, Case Explorer portion, click the Refresh Case Explorer button (looks kind of like the Green Recycle icon).
Click the plus sign in front of your deponent and double click the date of the deposition to open the transcript.
Next, copy the video files to the <drive letter>:\vs_data\CaseID\video directory.
Now choose QuickSync, Sync.
In the Select Deposition for Syncing window, use the drop down list to choose your new deposition. Click Ok.
The Auto-Syncer launches with this deposition loaded.
We are now on step three of the Auto-Syncing process.
Click the To Visionary button to load the synced depo back into your case. You will receive a message about replacing an existing depo, choose yes.
http://www.VisionaryLegal.com/
With those prerequisites set, we are ready to start.
Launch Visionary and open your case.
Use the File, Import, Transcript option.
- Browse to, select and Open the ASCII transcript.
- Enter the First and Last names of the Deponent. Ensure the spelling is correct.
- Enter the Date of the deposition. Again, ensure the information is correct.
- Click the Import button.
If you do not see your deponent listed, in the Visionary Shortcut bar, Case Explorer portion, click the Refresh Case Explorer button (looks kind of like the Green Recycle icon).
Click the plus sign in front of your deponent and double click the date of the deposition to open the transcript.
Next, copy the video files to the <drive letter>:\vs_data\CaseID\video directory.
Now choose QuickSync, Sync.
In the Select Deposition for Syncing window, use the drop down list to choose your new deposition. Click Ok.
The Auto-Syncer launches with this deposition loaded.
We are now on step three of the Auto-Syncing process.
- Associate your video files.
- Sync the deposition.
- QC the project.
- Publish the depo.
Click the To Visionary button to load the synced depo back into your case. You will receive a message about replacing an existing depo, choose yes.
http://www.VisionaryLegal.com/
Friday, April 1, 2011
Digital Signatures vice Graphical Signatures, Not Part Two, But an Interlude
In this post we discuss the digital signature process.
(Check out the first part to find out about Graphical Signatures, as we won't be discussing them here.)
A (not so short) digression into the world of Certifying Authorities. Read it for more information on the flow of certificates. There will be some reference in part two, to some of this information.
A Digital Signature is designed to re-assure the end user that YOU really signed this document or sent an e-mail.
It is based on the same technology that is used to assure web users that they really are at their banking web site or are at the Amazon store.
What we are talking about are Certificates and Certifying Authorities. When a web site wants to assure their users that they are at the true web site, the site owners get a certificate. This works on a Trust basis. There are several Trusted Root Certificate Authorities built into your browser. Perhaps the most well known is "VeriSign". GeoTrust and Thawte are two others that are installed in almost every browser. Any firm can purchase a certificate for their domain to allow them to be "trusted" When a certificate is purchased from a VeriSign, they conduct some type of check to see that the requestor actually is who they present themselves to be. Depending on the level of certification (usually based on the amount of maney paid), that may include a phone call, e-mail or maybe checking the firm with a source such as Dun and Bradstreet.
The Certifying Authority then sends the file and it gets installed on the web server. It is not a root certificate, but it is something that says that someone else believes they are who they say they are.
If you check your browser, you may have dozens of certificates, but there are only a few Trusted Root Certifying Authorities (TRCA). Almost every country has their own, simply because of country pride. Most of the other certificates, are chained or intermediate certificates. These certificates include the TRCA certificate indicating this chained certificate is backed by someone else.
Two other classes of certificates are self-signed and Trusted Root Certificates.
If a web site owner does not want to pay someone to vouch for them, they can create a self-signed certificate. This certificate basically says, "hey, you can trust me because I said that I am me." It's is the end-users choice whether to make that assumption or not.
Finally, a Trusted Root Certrificate can issued by an individual firm. Anyone can create a Certifiying Authority and become just like a VeriSign. They can choose their own level of verification and start issuing certificates to individuals (or firms for that matter). In this case, the browser would give a warning that a firm wants to install a Trusted Root Certificate onto the computer. It's the end-users choice. Once that certificate is installed, any of the certificates issued by that firm are trusted.
And finally there is the self-signed Trusted Root Certificate.
A self-signed Trusted Root Certificate allows a vendor to become a Certifying Authority. Suppose a vendor wants to be able to sell certificates to their clients. But they do not want to go through the hassle and cost of paying one of the real Trusted Root Authorities to be able to resell certificates that are automatically recognized by everyone. The vendor sets themselves up to be a Trusted Root Authority and starts selling certificates to their clients.
Everything is fine, until one of the clients end-users gets a digitally signed file and it it says the certificate is not recognized (or something similar). What has just occurred on the end-users computer is that the certificate used, does not have a chain back to a recognized Trusted Root Authority. So what the vendor does is include in the certificates that they sell to their clients, is a copy of their own Trusted Root Authority. The end-user has to install that vendors certificate and all the trust that entails. Once that occurs, any more certificates based off that Trusted Root Authority, will now be recognized.
This means that every single certificate that an end-user sees, must trace it's path back to a Trusted Root Authority. Either directly or via Intermediate certificates.
As you can see, digital certificates are not a simply concept. They are also fraught with potential issues. What happens if the TRCA itself gets compromised and duplicate certificates are issued? What if a client loses their certificate, how is revocation handled? These and many more questions should be considered before getting a certificate from someone other than one of the few recognized Trusted Root Authorities.
thanks for hanging in there through this long missive.
Go out and certify something!
chuck
http://www.VisionaryLegalTechnologies.com/
(Check out the first part to find out about Graphical Signatures, as we won't be discussing them here.)
A (not so short) digression into the world of Certifying Authorities. Read it for more information on the flow of certificates. There will be some reference in part two, to some of this information.
A Digital Signature is designed to re-assure the end user that YOU really signed this document or sent an e-mail.
It is based on the same technology that is used to assure web users that they really are at their banking web site or are at the Amazon store.
What we are talking about are Certificates and Certifying Authorities. When a web site wants to assure their users that they are at the true web site, the site owners get a certificate. This works on a Trust basis. There are several Trusted Root Certificate Authorities built into your browser. Perhaps the most well known is "VeriSign". GeoTrust and Thawte are two others that are installed in almost every browser. Any firm can purchase a certificate for their domain to allow them to be "trusted" When a certificate is purchased from a VeriSign, they conduct some type of check to see that the requestor actually is who they present themselves to be. Depending on the level of certification (usually based on the amount of maney paid), that may include a phone call, e-mail or maybe checking the firm with a source such as Dun and Bradstreet.
The Certifying Authority then sends the file and it gets installed on the web server. It is not a root certificate, but it is something that says that someone else believes they are who they say they are.
If you check your browser, you may have dozens of certificates, but there are only a few Trusted Root Certifying Authorities (TRCA). Almost every country has their own, simply because of country pride. Most of the other certificates, are chained or intermediate certificates. These certificates include the TRCA certificate indicating this chained certificate is backed by someone else.
Two other classes of certificates are self-signed and Trusted Root Certificates.
If a web site owner does not want to pay someone to vouch for them, they can create a self-signed certificate. This certificate basically says, "hey, you can trust me because I said that I am me." It's is the end-users choice whether to make that assumption or not.
Finally, a Trusted Root Certrificate can issued by an individual firm. Anyone can create a Certifiying Authority and become just like a VeriSign. They can choose their own level of verification and start issuing certificates to individuals (or firms for that matter). In this case, the browser would give a warning that a firm wants to install a Trusted Root Certificate onto the computer. It's the end-users choice. Once that certificate is installed, any of the certificates issued by that firm are trusted.
And finally there is the self-signed Trusted Root Certificate.
A self-signed Trusted Root Certificate allows a vendor to become a Certifying Authority. Suppose a vendor wants to be able to sell certificates to their clients. But they do not want to go through the hassle and cost of paying one of the real Trusted Root Authorities to be able to resell certificates that are automatically recognized by everyone. The vendor sets themselves up to be a Trusted Root Authority and starts selling certificates to their clients.
Everything is fine, until one of the clients end-users gets a digitally signed file and it it says the certificate is not recognized (or something similar). What has just occurred on the end-users computer is that the certificate used, does not have a chain back to a recognized Trusted Root Authority. So what the vendor does is include in the certificates that they sell to their clients, is a copy of their own Trusted Root Authority. The end-user has to install that vendors certificate and all the trust that entails. Once that occurs, any more certificates based off that Trusted Root Authority, will now be recognized.
This means that every single certificate that an end-user sees, must trace it's path back to a Trusted Root Authority. Either directly or via Intermediate certificates.
As you can see, digital certificates are not a simply concept. They are also fraught with potential issues. What happens if the TRCA itself gets compromised and duplicate certificates are issued? What if a client loses their certificate, how is revocation handled? These and many more questions should be considered before getting a certificate from someone other than one of the few recognized Trusted Root Authorities.
thanks for hanging in there through this long missive.
Go out and certify something!
chuck
http://www.VisionaryLegalTechnologies.com/
Subscribe to:
Posts (Atom)