Jarmo Hurri wrote:
Hi Sandy!

I think that the most important thing
that is missing is a more detailed pattern description. I _do_ need a
pattern database, but for my purposes, I should now what the fly is
built of: the materials.

The idea of storing the images of the flies elsewhere is tempting, but
I see that it could lead to a gradual degradation of your
database. The more patterns it would contain (the more time had passed
since its introduction), the more likely it would be that the oldest
images would no longer be available in their original locations.



Good feedback Jarmo. Thank you.
More deatailed description?
Nothing to it. I'll add an optional field.
I will populate this database (mostly) with spidering
program. I'll point my program at various well-known, already
existing sites suck in the text portions of those sites.
This is technical stuff I don't want to get in here.
But I can populate the database with thousands of pages,
that I find robotically. I do this stuff for a living, and I'm
good at it. The robotic program won't be able to put fly recipies
into queriable format. If a recipie is on the page you'll be able
to see it by following the link, but, for robotically-loaded pages
you wouldn't be able to query on recipe attributes:
select all dry flies where wing_type='split-wing' and
fly.component.wing.material.type = 'calf tail' and
fly.component.wing.material.color='white'

....that would be nice, but that level of detail can only happen
when somebody laboriously enters the data with a form.
I'll add that stuff to the form I posted. So some data (entered by
hand) can have a zillion attributes. Other data, entered by robot,
will be more sparsely described.

RE dead links. It's easy to find those. I can write a little perl
program that loops through all urls in my database, twice a week,
and pings the page. If it comes back as "404 not found" the program
removes it from the database. There won't be any dead links.

If users have photos they want to share, they could upload them
to a public archive site (there are many) and then fill out a form
describing their own fly. The descriptive data will live on my server.
The image will live on one of the photo sites. For Urls (in the
database)
that point to images, rather than html pages that contain images,
I can write a program that dynamically generates a page, that shows
the remote image plus all the descriptive data found in the database.

Many people have a browser option turned on that only shows images
"from the originating site" so that last option (dynamic pages
generated
at my site that show an image at another site) won't always work
for everybody. But what the hell.

Like I said, I do this for a living. My job title is "database
researcher."
So I'm pretty confident I can make a hotrod fly pattern database,
for use by many. The query interface will be public.
Those who want to enter data will have to "register" first and get
a (free) password. All of this will take time.

But the beginnings of it are happening now.
Should be a queriable interface by Christmas (most development happens
between 9:00pm and 11:00pm).