WeRelate talk:Digital library testing

Digital Library alpha testing [21 March 2008]

For starters:

Sign in worked fine.

On the page to modify my profile:

my given name appeared in the text box for last name, along with my last name. The given name text box was empty. System seemed to accept my modifications of the preference page.

Yes, DSpace has separate fields for given and surname, but MediaWiki just has a single full-name field. I'll combine the given and surname fields into a fullname field in DSpace to be compatible.

I did a little browsing just to get a feel for the site. Took a look at page "http://www.werelate.org/dlib/handle/64"; I was able to read it fine. Navigated away, and came back via back button on my browser. Now the page appeared blank. When I browsed backwards from there, every page I'd been to was blank.

I went back to your invitation and used the link you provided, and came to the same page as I initially reached (based on the address) but now it appeared blank.

So that pretty much stops me from doing any more with this tonight.

I just tried it now and it worked ok. I had to take the site down several times last night; perhaps you caught it during one of those times? Does the same problem happen today?

Bill--Q 23:08, 18 March 2008 (EDT)

Submission Process [22 March 2008]

21 March 2008, 6:00 PM

1. at http://www.werelate.org/dlib/submit

Successfully uploaded file in Word Format (Will of Thomas Scudder.doc) Verfying the file by “Clicking on the filenames above. This will download the file in a new browser window, so that you can check the contents.” The file was apparently downloaded, but did not open in a browser window. Instead it was stored as a Word file in my download folder. A quick glance at that file showed that it looked correct.

2. I clicked the checksum button, and got a result “5f8219b082d80f12d6c5a9ed1fbb73cf (MD5)” I did not attempt to verify that the checksum was correct, (and I will guess that very few users would spend much time on this. “Checksums” would not be part of “Drop dead easy”. I would also imagine that most folks wanting to check to see if the file was downloaded correctly will just view the file and see if it looks correct. Eventually I'll check the "Checksum" to see if its right, but probably wouldn't do this routinely.)

How about if I remove this button. It will probably generate more questions than it's worth.

Yes, more than likely. Most genealogists are not going to understand what "checksum" might mean. Q 22:25, 22 March 2008 (EDT)

3. I now find that the button sequence across the top of the page is actually clickable (contrary to earlier note), and will take you directly to whatever stage you need to look at, at least in a partially completed submission. Might not work if you are just starting a submission, and so haven't been to these stages. Will check this with a later submission to see how it actually works.

It looks like you can click on previous steps, but not later ones. Don't know what to do about this -- leave it as-is, or remove the clickability and the circles around the labels so that the labels don't look "clickable".

I found there was some (minor) some convenience to this, if you are coming back to a submission in process. Possibly you might want to allow the additional buttons to appear AFTER each stage is completed. Possibly "greyed out" and unclickable until the corresponding stage was completed. Q 22:25, 22 March 2008 (EDT)

That's a good idea.

Q 18:18, 21 March 2008 (EDT)

test [19 March 2008]

At http://www.werelate.org/dlib/submit

A. Third "button" from left says "Describe". So does the fourth.

B. Button's look like they should be clickable, but are obviously not intended to be clickable---possibly need a different design so folks aren't confused. The "Buttons" are much larger than the "next" button below, which may be a bit confusing to some. (After you figure out how it works, though, it shouldn't be a problem.

Good point. I'll address both A and B in the next couple of weeks.

C. Tried a submission of a fairly lengthy title, and the system hung, and eventually gave a message asking to try again, and if the problem peristed, submit a description. I tried again, Same thing.

Title was "Records of the First church in Huntington, Long Island, 1723-1779. Being the record kept by the Rev. Ebenezer Prime, the pastor during those years ; Containing lists of members of the church, and of baptisms and of marriages, a confession of faith, accounts of trials of members, and various other matters pertaining to the affairs of the church, with full index of names"

Message was "Internal System Error

The system has experienced an internal error. Please try to do what you were doing again, and if the problem persists, please contact us so we can fix the problem."

D. Tried a submission of a short title and the system gave a message "Error reading the source page (please try again later)"

--Q 09:10, 19 March 2008 (EDT)

I can see both C and D errors in the log and I think I've addressed them now. The internal system error isn't due to the long title but to a Source wiki page with an unexpected format. I've written a work-around, but can you tell me the title of the Source wiki page you had entered? The "error reading the source page" is due to the Source wiki page not being found - I fixed this so that the system tells you so instead of giving an error.

hmm! not sure about this. What I was working from was "Source:Scudder, 1899", but I just cut and pasted the title from that, rather than navigating to it. So I'm not sure how this would have worked. Also, I've got snippets from Source:Scudder, 1899 under titles like MySource:Scudder, 1899-89.jpg (denoting an image of page 89 from Scudder, 1899.---the hyphen is what th system substitutes when I use the more conventional colon to indicate a page, viz MySource:Scudder, 1899:89.jpg.

That explains the problem I was seeing. Source:Scudder, 1899 doesn't have any metadata associated with it, and the program wasn't initially expecting that case. It is now. If the "source page not found" error happens again, please let me know. Hopefully it won't. (The system accepts just Source titles, not MySource titles.)

On another related matter, I (continue to) see a disconnect in what is meant by "source". In the Digital library content area things were listed under something called "Source". What was there were the titles of the items of concern. (e.g, "Register of the Freedmen's Bank....". For items like this there is no obvious author, but for other items that might be included (e.g, Source:Scudder, 1899, which gives an index/abstract to marriages, baptisms, etc for a specific church on Long Island), there's a definite author, and the full title is VERY long.

Overall, its easier to remember author date than to get the title exactly right. But in the case of the Freedmen's Bank Register, there's no Author to begin with. You might want to consider something like "Freedmens Bank Register, 1875" then give the bibliographic citation. Anything to keep what's being used as the primary identifier limited to something fairly short.

Complex problems these. There are so many different variations on the theme, that no one style can fit everything. When people are working separately, they can make things fit what ever makes sense to them. This collective approach is a bit harder in terms of documentation. The fastidious part of me says "You want an exact answer for everything". And the realistic part of me says "Yeah, sure, when cows fly. In the meantime, use an approximation."--Q

I agree that we need to come up with some rules for source page titles. The upcoming new "Add page" for sources should help, since the system will generate the source title based upon 1-2 pieces of user-entered metadata. I also agree that the Freedmen's source and item titles seem pretty long to me, but that's how they want to list them. With the item titles being listed next to the Source page title, I would think that most item titles could be kept pretty short. I've listed a first-cut at rules for Source page titles in the "Source page titles" section of WeRelate talk:Source Committee. Perhaps we should ask people to enter a shortened source title for the Source page title if the full source title is very long. Could you share your thoughts on the WeRelate talk:Source Committee page?--Dallan 11:44, 20 March 2008 (EDT)

Viewing Records [22 March 2008]

1. "Simple Metadata Record"

http://www.werelate.org/dlib/handle/68

A. Field “URL”----when the input page for this field is offered to the user, it needs to be clear that “URL” refers to the WeRelate Source article, not where this can be found on the web. This goes along with the point that “Source” refers to a WeRelate article title, and that the DigitalLibrary is intended to work with WeRelate articles. This may become intuitive when the link between the two is more clearly established. But right now the Digital library looks to be a separate entity.

Actually, the "URL" field can refer to any web page. We already ask for the Source page title in a different field, so the URL might refer to an image at Ancestry that you're making a transcription of for example.

B. This page does not have a convenient Title. Its apparently something like "Simple Metadata Record", but that doesn't appear on page. Perhaps no nvermind, but having a Title would make it easier to refer to this page.

I'll add a title.

2. Full metadata record http://www.werelate.org/dlib/handle/68?mode=full&submit_simple=Show+full+item+record

• The drop down menus for the input fields that generated this page allowed the user to select only one value, though several might apply. For example, the church records used in this example were from the First Church of Huntington, on Long Island. That church (and the earliest records in the source document) started out as a Congregationalist congregation, but ended up Presbyterian. You could legitimately fill in either Congregationalist or Presbyterian. You couldn’t possibly provide options for all possible combinations of religions. Perhaps you could make some of these fields free form text boxes (or give an “Other” option, that when selected would pull up a free form text box.)

I'd like to keep the drop-downs single-valued if possible to reduce the number of buttons on-screen, but I could make them repeatable like the name and place fields if you think the need for multiple values will be semi-frequent.

Hard to say. I can see it coming up with some frequency. Not common for religion, but probably expectable for ethnicity. As an example, even though membership of this particular church was predominantly English, other ethnic groups can be expected in this community, and in fact some members were not of English ancestry. Obvious examples would be the slave baptisms and folks with Dutch ancestry---but there were many different nationalities on Long Island from the earliest dates, and you can expect to see any of them mixed in with the records. Now, if the records are intended to be entries for a single person, then this may be OBE, and non-problematic. But I think it very likely that most entries will be for multiple persons as was the case in this instance. Q 14:33, 20 March 2008 (EDT)

I can see this could become problematic. The intent of the ethnicity, religion, and occupation fields is to describe the collection of records for the entire source. I wasn't even going to put them on the digital library - just leave them on the Source page (eventually we'll add these fields to the Source page). I added them to the digital library so that people could override or enter values that weren't on the Source page. I could make them repeatable, but I don't want to encourage people to use them to describe individuals because there's no easy way to associate a different religion, ethnicity, or occupation with each name listed in the item. I need to think about this -- perhaps it would generate less confusion to put these fields only on Source pages, and let people list occupations, religions, ethnicities, and any other identifying characteristics associated with people in the digital library items as keywords in the description field.--Dallan 20:24, 22 March 2008 (EDT)

• dc.identifier.uri---some of these labels are a bit obscure. This one is obvious enough---but some of them like dc.identifier.fh are not at all obvious. Possible different labels are needed if this is going to be accessible by all users.
• A text explanation of the labels may be needed, unless this is intended strictly for management viewing.

I need to change all of the labels to their "human-readable" equivalents.

• “File Name” and the associated link, and the link “View/Open” seem to take you to the same place, and so are redundant.

I'll remove the view/open link.

• dc.relation.uri ---contains the link I input as a web resource containing a full electronic copy of the original. I don’t know if that’s actually what I was supposed to enter in the original input box. But this label doesn’t suggest that I got it right. Which probably means the input box needs to be made more clear, or this label more intuitive.

You got it right -- this field contains the URL of a web page upon which this submission is based. I'll go through all of the labels and on this page and change them to their human-readable equivalents.

• There doesn’t seem to be anyway to edit the metadata entries, at least on this page, or the “simple” page.

Editing metadata is an interesting question. The software emphasizes preservation, and doesn't allow the submitter to edit what they've submitted once it's been submitted. There is a back door for an administrator to edit the metadata, but it's pretty low-level and not something I'd want to put in front of users. To allow people to edit the metadata associated with particular items I'll need to add some additional functionality.

I guess I will have to be extra careful about getting it right the first time. Good thing this is in the sandbox though. I am definetly error prone, and prefer to get it in, and correct later. Enter once, and correct a million times seems to work best for me. (G) Q 14:24, 20 March 2008 (EDT)

It's a good idea, it will just take awhile to implement. But it will probably have to be implemented prior to opening up the digital library to everyone though.--Dallan 20:24, 22 March 2008 (EDT)

--Q

Sources [22 March 2008]

A. http://www.werelate.org/dlib/handle/67. This item includes the descriptive title that belongs to the succeeding item at http://www.werelate.org/dlib/handle/68. I presume that something has misaligned in the database.

Are you sure? I submitted item 67 when I was testing long titles. I used the long title that had failed for you earlier, and which it looks like you shortened for item 68.

Yes, it doesn't match the source. That's something else. Perhaps if you were simply testing title length, then the disconnect is incidental. But 67 and 68 are two definitely different sources, but the title is the same. Q 14:38, 20 March 2008 (EDT)

I think it's incidental, but I'll watch out for it in the future. (When I upload test items, they usually have no basis in reality because I have very few scanned genealogy artifacts laying around. Take a look at the image for example. It's from a talk I gave once. :-)--Dallan 20:24, 22 March 2008 (EDT)

B. http://www.werelate.org/dlib/browse?type=dateaccessioned&sort_by=1&order=DESC&rpp=20&submit_browse=Update There needs to be some simple explanatory information added about what various data elements refer to at

Specifically

1. "Source" Refers to a specific article in the Source Namespace on WeRelate. 2. "Title" refers to a specific item within that source; eg., a specific page, or an identifiable record, etc. "Title" may not be the best choice for this since it can be confused with the title of the source

I don't like title either; I've been trying to think of a good substitute but haven't been able to come up with anything yet. I'm thinking that when we integrate with the wiki, the digital library items could be linked to using [[dlib:source title/item title]] so using "Title" for the Item Title is again confusing because in a sense, the source+item titles together form the "title". I've thought about changing it to "Item title" or "Record name" (that's what appears in the submission screen), but I'm not sure.

C. If the process used here is to add materials in the Sandbox, and then let the system add them from the sandbox into the Library itself, perhaps that needs to be explained. Or perhaps there are two entry ways envisioned? one through the sandbox, and one more directly? The sandbox approach seems reasonable since it adds a layer of security to prevent "bad" adds. If that's the approach to be used, perhaps a different name would be in order, as it has certain implications in the wiki worlds. (Ie, nothing you do in the sandbox is permanent--all changes are written in sand, (hence, "sandbox"), and nothing is retained long term.

The purpose of the sandbox is just as a place for people to test uploading things to the library. Eventually items in the sandbox will be deleted. I don't envision them moving sandbox items into the library. Each user will get their own collection that they can add items into (you have one right now). In the "wiki" spirit, I thought that I would let user-collection items go through without review. If necessary, I can delete bad items after they've been submitted. Alternatively, we can also create collections for genealogical societies and project teams, like "Lowcountry Africana". The administrators for these collections can limit who can submit to them, and we can add a review step to the submission process so that an administrator has to review submitted items before they are published.

D. Possibly there is a a need to create different types of "Source" cards in WeRelate itself. e.g.,

1. A book source 2. A journal/magazine/newspaper source 3. A Bible Record 4. A Census record 5. A vital statistic record for birth, death, marriage, burial, baptism, etc. 6. A Will 7. etc

Click on the appropriate item in a pulldown menu would take you to a page with text boxes for specific data elements unique to that kind of item.

One of the advantages of this would be that the end user wouldn't be presented with options for entering information that obviously didn't apply to the type of source they were working with---for example, asking for a volume number for a bible record, or the publisher for a will record. If you like I can draft something up that would give the basic information data fields needed for different record types

I agree. I tried to come up with a first-cut proposal for this in the "Fields to Gather on Source Pages" section of WeRelate talk:Source Committee. Please feel free to edit/extend it.

I will come back to that in a day or so. There's a lot of thought available in the Source discussion forum. Possibly this is something you'd like to see done as a group.

--Q

Simple Metadata

http://www.werelate.org/dlib/handle/68

The button that says “show Full item”----is misleading. It suggests that clicking this button will show you the complete record content---ie, the record contained in the file that’s been stored here, rather than a more complete listing of MetaDataa. Perhaps “Show Complete Metadata” would be better

Will do.

Collection home page

http://www.werelate.org/dlib/handle/58

Browse buttons “Source and Title” and “Submission Date” are on staggerd lines. It would look better if they were on the same line. Once someone has subscribed to a collection, perhaps the offer for them to “subscribe”, should be replaced with “unsubscribe”. In the top pull down menu, perhaps the label “In:” might be replaced with “Select Collection” as being more intuitive. Consider replaceing “Search” with “Search this collection”. It’s a bit more bulky, and perhaps the simle label is better for that reason. Ditto “Browse” vice “Browse this Collection”

I've added these as well.

Full metadata record

http://www.werelate.org/dlib/handle/67

At: http://www.werelate.org/dlib/handle/67?mode=full&submit_simple=Show+full+item+record

Some how the description of another record has been entered on both the dc.title, and dc.browsekey. Possibly this happened during creation and was deliberate (though unintentional) by the user, or perhaps theres a problem in retrieval.

This is a record I submitted. I "borrowed" one of your titles to test it. The "dc.browsekey" needs to be removed from this screen. It's an internal-use-only metadata element so that we can display items sorted by source and item title. (DSpace allows you to sort by only one field, so I created the browsekey field as a concatenation of the two fields I wanted to sort by.)

Also, "dc.rights" needs to be displayed with links to the licenses.

Submission Process [21 April 2008]

http://www.werelate.org/dlib/submit

Possibly needs a page title : eg., Submission Process

I'll add a title

I was going to play around in the sandbox at the DL and while going through the submission process, I decided I wanted to quit and go back to the Home page, but didn't see a way to quit the process other than closing the window down. Perhaps I overlooked it, but is there a "quit" link? --Ronni 12:26, 18 April 2008 (EDT)

There's a "Save/Cancel" button that means "Quit", but in looking into this I just realized that I neglected to add it to the "Select source" page. I'll add renaming that button to "Quit" and adding it to the "Select source" page to the todo list. I'm spending the next few weeks working on search and starting match/merge, so I probably won't work on the digital library todo list until May/June.--Dallan 11:18, 21 April 2008 (EDT)

License step [21 March 2008]

First item in text is labeled “There is one last step”. That might (or might not) make sense for some entry ways, but at first glance this is misleading. Its not the “Last step” that’s being discussed but the first thing to be done.

Yes, I need to reword this (the license selection step used to be the last step).

The options here include a good selection of possibilities, but I think one is dissappearing through the cracks. Specifically, there may be some items that are out of copyright, but have been obtained from a source that requires you to agree to a restrictive license. Ancestry’s “Census Images” being a case in point. While Ancestry allows individual users to reuse those images for their personal genealogy, I think they would draw the line at massive imports of their images into this Digital Library. There’s a grey area here, and some will argue that such restrictive licenses are not binding. No lawyer here, but I strongly suspect such arguments are smiply self serving, and if tested I wouldn’t want to be on the receiving end of the counter argument, as that’s the one that I personally (and non-professionally) think would prevail. This is an issue that has been at least spoken to on the WeRelate watercooler, but I don’t think there’s a sound resolution on this at this time. The defacto position is that its OK as long as you are only supporting your own genealogy---which of course is what virtually everyone is currently doing. It’s a different matter when you start collecting these things in mass, and providing the mechanism to facilitate that may be a problem for you at some point in the future. One partial solution might be to include a button here that discusses this issue “Restrictive License Applies”, and have the discussion clearly explain that such items are being downloaded in specific support of someone’s personal genealogy, and are in compliance with the applicable restrictive license. My guess is that this would be perceived as a transparent fiction, but at least you’d be laying the ground work for why this might be OK. It’s a rationale. Whether its good or not is another matter. Eventually, I suspect that Ancestry and others are going to tighten up their restrictive license so that this can’t be done at all, but its all pretty grey at the moment. I presume you have a lawyer dealing with the legalities of running this site. Probably be a good thing to get a legal opinion on something like this.

I agree this is a grey area. Ancestry would argue that although NARA microfilms are not under copyright, their digital images of them are. On the advice of a lawyer, we've registered a designated agent to receive claims of copyright infringement at the copyright office (see this document). If someone contacts us about copyright infringement we'll remove the offending items.

I'll add a "Restrictive License Applies" license option along with a field for the user to identify the copyright holder and describe the license as a new license option. That's a good catch.

Good. I don't think Ancestry would claim that their images are copyrighted. Lots of people do things like this, and slap "copyright" on someone else's work simply because theretyped/scanned the material and put it on a website. You see this a fair bit on GoogleBooks, where they've gotten a scan of an old, out of copyright work from a re-publisher, and the republishe claims copyright. I think they can do that legitimately only for works where they've added something (like a new index, or a forward, etc) but the words of the original are out of copyright, and I doubt that they can claim a new copyright for them. No case law here, I think, so this is in limbo. For me, it seems like they are making a farfetched selfserving argument, but my view doesn't count. However, Ancestry is not doing that. I do not believe they are making a copyright claim. Only restricting your use of the material if you get it from them. That, I think, is quite reasonable. This is a really interesting question for genealogists, and one which I image will be resolved in court one day. Q 16:07, 21 March 2008 (EDT)

D. “Click on one of the buttons at the bottom of the page.”

The buttons are at the side of the page, not the bottom. It might be convenient for experiened users if you placed a button strip near the top of the page, before the explanatory material. But perhaps you want to be sure everyone has had to at least allowed their eyes to pass over the explanatory text on the way to finding the right button. Not convenient, but perhaps necessary.

Under “Are you the author?”

"derivative works" Probably needs a link to something explaining what a derivative work amounts to, and doesn’t amount to. You explained it once to me, and that was good enough for me to know what I might or might not be able to do, but I don’t think the phrase is sufficiently intuitive that others would immediately understand the limitations and potential.

Good point. I'll add a link to this wikipedia article.

Source entry step

Tried to submit the following: MySource:Will of Thomas Scudder (1657/58)

Message came up to give a title of a Source on WeRelate. 

a) Possibly need to make it clear that only sources already in the Source: namespace on WeRelate can be used.

I'll do this; I'm also going to add a "Add New Source / Search Sources" button that will pop open a window where you can add a new Source page (and search source pages).

b) I presume that eventually there will be an option when you create a source on WeRelate to go to the digital library and download an item from that source.

There will eventually be a way to list the digital library items associated with a Source wiki page. And you'll be able to cite digital library items on Person/Family pages.

c) When the warning message popped up a white rectangle was superimposed over the field, partially obscuring the input box for the “source page title”. Dissappeared when I edited the input box, which is good. But it shouldn’t have been displayed in the first place.

That's odd. I haven't seen this. What browser/OS are you using?

d) I converted the MySource item to a source item, and resubmitted, without problem.

First "Describe" step [23 March 2008]

a) “Enter the URL of an image or record upon which this submission is based.” Not sure why this is here. Seems like this is going to be added automatically based on the WeRelate Source page. Asking for it here seems i) to increase work unnecessarily, ii) invite people adding in other links to places on the web, that will be subsequently ignored. So I left this blank to see what would happen if I entered nothing at all

The intent for this field is to give people a chance to enter the URL of an image that they're basing a transcription on, say an image at Ancestry.com, if they're uploading just a transcription and not the image as well. The same thing might also apply to a partial transcription of an on-line book at Google. I'm open to re-wording suggestions to make it clearer. Maybe "If you are uploading a transcription of an online image/document, enter the URL of the image/document" or "If this item is based upon an online image or document, enter the image/document URL"?

I misunderstood something from a previous session. Seems like "URL" is being used in multiple ways, and is context dependent. Therefore may need something to indicate what is meant each time it comes up. In this case perhaps something like "Electronic Source"? Q 14:45, 20 March 2008 (EDT)

Yes, there are two URLs that could be stored for an item: the URL of the item itself, and optionally also the URL of an external resources upon which this item is based. Both show up when you're looking at the full item metadata. I'll make sure that they're better-distinguished.--Dallan 20:24, 22 March 2008 (EDT)

b) Entering nothing at all did not create a problem

Only the Source page title and item title fields are required.

Perhaps there needs to be an asteriks besides the fields that are required. Q 14:45, 20 March 2008 (EDT)

That's a good idea.--Dallan 20:24, 22 March 2008 (EDT)

Second "Describe" Step [25 March 2008]

1. it’s a fair bit of work adding every persons name mentioned. I probably would not do that routinely.

I agree.

2. A white rectangle obscured most of the last five input boxes, though I could click on the pull down’s and see the choices. Couldn’t review the choices made after selecting something, as the rectangle obscured the boxes.

So there's the white rectangle again. That's really odd. I've never seen it. I'd be very interested in knowing what browser you're using.--Dallan 13:11, 20 March 2008 (EDT)

Safari. And that probably IS the cause of the problem. I can shift to FireFox. IE is no longer supported for my machine. But I bet that I'll detect more obscure problems with Safari than anything else. (that is, I'll still get lots of the FireFox errors, plus some of the ones unique to Safari. Q 14:45, 20 March 2008 (EDT)

I keep an iMac running Safari for just this reason. I'll fire it up next week and see if I can figure out what's going on. (Probably toward the end of next week, because I really need to finish the new Source + Repository changes.--Dallan 20:24, 22 March 2008 (EDT)

3. In the second describe step there's a pull down menu for "Subject". The menu items are things like Biography, Cemetery Record, Will, etc.

a) "Subject" doesn't exactly correspond with the content of the menu. This is more like "Type of Format" or "Type of Record" which we've discussed elsewhere.

b) The list of items in the menu seems quite comprehensive, but I noticed a missing item, namely "Letter" or "Correspondance". There are probably other things that can be routinely expected to show up as well, but we'll probably only ferret them out when the issues arises. That will reveal itself as soon as people start using the Digital library on a day to day basis. Q 15:49, 23 March 2008 (EDT)

I agree we'll have to add more categories over time. By the way, I'm planning to move the Subject field to the Source page (and call it Category). I'm planning to move Ethnicity, Religion, and Occupation to the Source page as well. If people want to record the specific ethnicity, religion, and/or occupation of the people appearing in the records, they can add those as keywords. But the "Ethnicity" field is really meant to be a sub-category of the "Ethnic/Cultural" category on Sources. Similarly for Religion (sub-category of "Church records") and Occupation (sub-category of "Occupation").--Dallan 11:53, 25 March 2008 (EDT)

Searching User Space [21 March 2008]

21 March 2008, 9:45 AM

1. http://www.werelate.org/dlib/handle/55

Page shows at top: “User community Community home page …. Introductory text …. Collections in this community” … Copyright Text”

A. User community seems to be redundant to Community Home page. Recommend substituting “User Communtiy Home Page” or something of that sort

Good point.

B. There’s no “Introductory text to go along with the caption “Introductory Text”. I assume this is a place holder waiting in the wings to be filled.

Right.

C. “Collections in this community” seems a bit obscure. What’s shown is a list of users. Presumably each user has a collection of sources that they are working on. I would guess that this will be clarified in the introductory paragraph.

Yes, each user that logs into the digital library will get a collection with the same name as their user name in the "User community", which they can add items into. I'll explain that in the intro.

I see, sort of, what's happening. If I go into My DSpace, I can search/brose, what I've input. But if I go in through Communities, and select Quolla 6, it doesn't seem able to find the articles I've submitted. Possibly that's intended, but then why can I search the Quolla6 space at all?

D. The list of users (or perhaps that’s “List of Collections of users” is in fairly large type face. As more users/Collections are added this may be awkward. Recommend smaller font.

Ok. We'll also have to make this list scrollable.

E. I don’t know what is meant by “copyright text”. Is this something that’s going to be added, or is this a statement that the text on the page is copyrighted? In anycase, is this desirable on a wiki? Perhaps this is leftover from Dspace incarnation.

It was a placeholder to find out where it would be displayed. I'll remove it.

2. Quolla6 Collections Home Page http://www.werelate.org/dlib/handle/58

A. When I do a search in the search box, but leave the search field empty, I get result of “1”---which might (see item C) be the number of articles I’ve created in this area.

I'll fix that.

B. After I do a search, I end up on a page from which I can do more searches, but I can’t return to “browse mode”, without backclicking. Recommend that an option be put in to allow the user to continue from this point by browseing if they wish.

You should be able to do that now with the new menu on the top.

C. When I browse my own collection I get the message “There are no entries in the index for Collection "Quolla6". Thought there was at least one entry in this collection. In fact, Dallan pointed it out. So today its gone. D’unt understand.

I did a search on Quolla6 and got two results. The first was uploaded to the sandbox. The second was uploaded to the Quolla6 collection. But the second item does show up when I browse the Quolla6 collection.

D. When I return to my User page from this point (following link Quolla6) I do get back to my user page. However, when I changed the pulldown to search “All of Dspace” or “User Community”, I get the message “There are no entries in the index for Collection "Quolla6".

I suspect that its not responding to the menu items after searching Quolla6 space. (When I go to MyDSpace area I can search Quolla6 DSpace just fine. Q 16:17, 21 March 2008 (EDT))

I think the issue is that the pulldown only applies to the Search button. When you click on the one of the two browse buttons you're browsing that collection, regardless of what the search dropdown says. I'll have to separate these two dialogs. Putting them together as they are creates confusion.

Q 16:08, 21 March 2008 (EDT)

Simplfied skin; introduced bug [21 March 2008]

I just installed a simplified skin and introduced a bug: the "Recent Submissions" list on the left-hand side of Community and Collection homepages does not always show the recent submissions for the community/collection you are looking at. I know what the problem is. I'll fix it tomorrow morning.--Dallan 19:26, 21 March 2008 (EDT)

BTW, the problem's been fixed.--Dallan 20:24, 22 March 2008 (EDT)

Several questions regarding entering extracts from microfilm [21 March 2008]

I have decided to abstract data from microfilm for 24 families from Richland County, South Carolina and submit the abstracts to the digital library. I have not started this project and I have a few questions before I begin. I first establish a source in the Wiki. Then may I type the abstract in Word and then upload this to the digital library? I intend to complete one family abstract and upload, etc.

Right.

Will one eventually have other categories in the digital library or will these abstracts always remain under my name (community)? Richland County, South Carolina could be the community name.

Every collection has to have an administrator -- someone responsible for the submissions to that collection. You're the administrator for your own collection, but "Richland County, South Carolina" would need someone willing to monitor submissions to that collection. If a group of people wanted to get together and say that they'd be interested in monitoring such a collection, I'd be happy to create it.

Also in abstracts it is generally accepted to use a question mark enclosed by square brackets when uncertain of a word or phrase; and one also uses square brackets to clarify data or to add a comment. May I use square brackets and the question mark; if not what does one suggest using?

That sounds fine to me.

I usually share my abstracts with other societies and sites. I assume this is permissible as long as I use the license of use for the digital library and specify that the society, etc. must accept this usage or not have the data. --Beth 19:54, 21 March 2008 (EDT)

As the author of the abstract, you hold the copyright (assuming that it's copyrightable -- doesn't contain facts only and isn't just a transcription of an out-of-copyright document). You don't lose your copyright by submitting the item to the digital library. This means that you can give it to whoever you want, under any conditions that you want, even under a different license than the one you assigned when you uploaded the item to the digital library. So if someone downloads the item from the digital library without talking to you, then they'll get the license you assigned. But if they talk to you and ask you for a different license, as the copyright holder you could give them a different license if you want. Bottom line is yes, you can share your abstracts with whoever you want.--Dallan 20:24, 22 March 2008 (EDT)

Submissions List [22 March 2008]

21 March 2008, 10:15 PM

1. New skin

A. helpful, and substantial improvement. "Signed in as" display particularly good to have.

B. Looks like the link bar at the top is misaligned. Would look better if the search box, "Signed in as" , and Sign out links were all on the same line as "Home", "Search" etc.

I'm not sure both would fit on the same line on smaller monitors. How about right-justifying both the top and bottom lines?

Good point. Its a really minor kind of thing, so maybe leaving it alone would be best. Doesn't look bad---just unusual style.

2. Testing the "Browse function"

A. Source, Title, and Submitted Display

i) I see I should have picked a different "Source" for the Will of Thomas Scudder. In this case, the Source should (perhaps?) have been GenForum? The "Item" is the will of Thomas Scudder, but I got it from a message on GenForum. If I'm confused about what to put, I'm sure others will be as well.

ii) Might be helpful to indicate which collection the item is in.

Ok.

iii) recommend smaller font.

Ok.

iv) I changed the number of results per page to 100. Looked like it changed accordingly, but there was a huge difference in the appearance of the display. Specifically, the width of the "Source" column shrunk, and the "title" column expanded. NAppears that the HTML is adjusting to fit a really long title---which happens to be where you spliced the long title for Records of First Church of Huntington, onto a source "Elizabeth A. Powell Diary". This may be a no nevermind, but the jump from one layout to the other was disconcerting. The smaller font would minimize the problem, but perhaps a fixed field width would be better.

That's a good idea.

B. Browseing by Source and Title,

1. Tested the "Jump to" Function. i) the letters you select from seem to be mismatched with where you go. For example, if you select "B", expecting to get a list of sources beginning with the letter B, you actually get a list beginning with the letter A . Similarily, selecting "X" gets you a list begining with "W". if there was something in the list of items that began with the particular letter, but if not,

The problem is if there aren't enough sources to fill the entire screen, the system backs up in the alphabet until you get enough sources. I'm going to change that behavior so that it doesn't back up.

ii) It looks like if no titles begin with the letter you select, you get a list of things that begin with the letter "R". Not sure that's the exact rule that's prevailing, but what you probably should be getting is something like "Nothing matches your selection".

I was thinking that if you entered R, you'd get items starting with R, S, T, or whatever titles fell next in the alphabet.

iii) sometimes you get more than just the matches you were seeking. For example, pressing X (in lieu of W), you get a first entry beginning "Will...", which is good, but then you also get things begining with "S", "R", etc. sort of in reverse alphabetical order.

iv) The browse function is described as "By Source and Title", but the jump to function seems to be strictly "Source". Perhaps the "Jump To" function needs to specific which of the two will be searched for retrieval. Conceiveably it would be useful to select either "Source", "Title" as the basis for the " Jump to".

Yes, jump effectively uses just the Source field, since under the covers we're sorting/jumping by a concatenation of "source title + item title". So if you enter an "R", you effectively jump to the first source starting with an "R", and the first item within that source. Let me think more about this.

Q 21:47, 21 March 2008 (EDT)

Browsing by Date [24 March 2008]

page title: Browsing by Submission date http://www.werelate.org/dlib/browse?type=dateaccessioned&sort_by=1&order=DESC&rpp=100&year=2007&month=1&starts_with=

1. If the search field is the submission date, then the pull down menu is mostly filled with meaningless options (search in 2007, 2006, etc.). If the search function is keying on something else, this needs to be spelled out.

No it's keying on submission date. I'll remove the year option until we hit 2009.

2. if you type in a date before 2008, you still get the same list.

Same problem as before -- the system is trying to return a full set of results to it backs up.

Q 17:51, 22 March 2008 (EDT)

Sorting by Source and Title [22 March 2008]

Page titled Browsing by Source & Title http://www.werelate.org/dlib/browse?type=browsekey&sort_by=2&order=ASC&rpp=100&starts_with=B

1. If you use the "Jump To" function, you now get a page appropriate to the letter selected.---unless there are no entries under that letter. In which case you get the nexxt thing on the alphabetical list (I think). For example, the URL above gives a search for things beginning with "B"; There are none, so the first thing that appears is a Source "Elizabeth A. Powell...." ---Q 17:54, 22 March 2008 (EDT)

Yes. Thanks for your testing!!--Dallan 20:24, 22 March 2008 (EDT)

Feedback page [22 March 2008]

Help Contents: http://www.werelate.org/dlib/feedback

1. Tested the "Feedback" contact form. Waiting for acknowledgement of receipt of query.

It worked. Got feedback from Dallan Q 22:46, 22 March 2008 (EDT)

2. Checked the links at the bottom of the feedback page. All worked. Note that there's a link to the feedback page itself, which seems redundant. Click the link and you return to the same page where you clicked the link.

3.Checked links at top of page. All worked

DSPACE HELP [25 March 2008]

http://www.werelate.org/dlib/help/index.html

1. Tested menu of links. All took me to the proper place.--

2. Note: The last item on the page is "For Further assistance". This is not included in the menu at the top of the page.

3. Checked links at bottom. All worked. However, the list of links provided here is not the same as provided in the menu at the top of the page. In addition to not includeing "For Further Assistance", the links at the bottom of the page do not include

• Advanced Search
• Subject Category Search
• Sign on to Dspace
• Handles

4. I have not reviewed the content of the various help items. However, I did notice this statement in "Communities"

Communities which can correspond to administrative entities such as schools, departments, labs and research centers.

While this doesn't say that a community couldn't simply be a group of folks combining together to work in some particular area, there's a strong implication in this statement that communities are associated with some formal organization. I suspect this is left over from the main DSpace boiler plate, but you might want to consider whether it should be changed for a genealogy context where most of the members are not part of a formal organization.

Q 20:35, 22 March 2008 (EDT)

Actually, the entire help page is left over from the main DSpace boiler plate :-). I'll move it to a wiki help page and re-write it.--Dallan 11:53, 25 March 2008 (EDT)

Remember Me Function [25 March 2008]

When you register you get an option to "Remember me on this computer". I've come acrossed it in a couple of places but didn't note exactly where. However, while I've checked the Remember me option the system doesn't seem to remember me at all, as I've had to sign in each time I've gone to the Digital LIbrary, at least if I've been gone for more than an hour or so. If I leave and come right back it does seem to remember me, probably as a function of what's happening in my cache.--Q 21:52, 22 March 2008 (EDT)

I agree this is annoying. The problem is that DSpace doesn't have a "remember me" function, and currently the two sessions aren't tied together -- so even though you're signed in to the wiki, you still have to sign in to DSpace. I'll fix this by tie-ing the DSpace session to the wiki session so you'll only have to sign in once, and the system will remember you.--Dallan 11:53, 25 March 2008 (EDT)

Password notification [24 March 2008]

Testing password reminder system at http://www.werelate.org/dlib/dbauth-login

1. Asked system to "remind me" of password.

2. It successfully sent me a new password via email

3. Ignored new password, and, as the notification suggested, the old password still worked.

4. Logged out, and tried the new password, and it didn't work. That was expected since I'd previously signed in with the old password.

5. Went through the cycle again, but this time used the provided password first pass through. It worked fine.

Q 09:37, 23 March 2008 (EDT)

Your Subscriptions [24 March 2008]

testing links and buttons at http://www.werelate.org/dlib/subscribe

1. Links in the top and bottom banners all work. Since this is a standard feature, I won't test these further on other pages, unless a need is seen

2. Tested "Unsubscribe" function for a specific collection. It worked.

3. Tested "Unsubscribe All" function. it worked.

4. Tested the "Help..." link on the right hand side. It worked and took me to the appropriate help page. that page was different from the help link in the banner, but specific to this page.

5. The Subscription page gives the direction "To subscribe to a collection, visit the collection's home page, and click on the "Subscribe" button." The "help" page tells you to :

1. go to the DSpace registration page by clicking on the sign-on link in the navigation bar on the left of the home page
2. fill out the registration form
3. navigate to a collection for which you would like to receive e-mail alerts, and click on the "subscribe" button (repeat for other collections)
4. to edit your subscriptions, go to the "Subscribe" page.

A. I don't know what the "DSpace registration page" is. Its not an obvious link from the home page, and not given as a link from this help page. its not also listed as an item in the master help page. I'm sure I've been there (I think I'm "registered"), but I just don't know how to get back to it quickly from the information supplied here.

B. The guidance on the page itself as to how to subscribe to a collection is a lot more straight forward, but, perhaps the help guidance includes additional information with the intent of guiding someone who hasn't registered.

That's the problem. The "subscribe help" should assume that the person has already registered. I'll fix this. Thank-you!--Dallan 11:53, 25 March 2008 (EDT)

Q 10:14, 23 March 2008 (EDT)

Changes [26 March 2008]

Yesterday I added the ability to sort items by item title in addition to the existing source title and submission date sort orders when browsing. I also changed the submission process so that entering multiple names is faster: you can enter multiple individuals' names on separate lines of a single text box. Finally, I removed the Subject, Occupation, Religion, Ethnicity, URL, and FHL/NARA/ISBN identifier fields. I'm going to add these fields to the Source wiki page, so having them also on digital library items would be redundant (and was getting confusing). In the case where the item could be found in multiple repositories (e.g., a will that could be found in a book in a library, a record collection in a county recorder's office, or in a bulletin board message on the Internet), and you'd like to record the specific repository from which you obtained your transcription of the will, I'm thinking that information could either go into the "Description/keywords" field, or we could add two fields: "Repository" and "Location within repository" to the digital library item.

We're going to be hosting records for the Lowcountry Africana website. Over the next several days they will be modifying the "look" of the digital library to match the look of their website. Eventually we'll integrate the digital library into the wiki, we'll make the default "look" match the look of WeRelate.org, and we'll give other organizations the ability to frame the digital library inside their websites and give it a custom "look" to match their website that appears only when the digital library is framed. We don't have that capability today, and Lowcountry Africana is launching at the end of this week, so we're letting them change the default "look".--Dallan 11:33, 26 March 2008 (EDT)

I just checked out the LowCountry site (very nice site btw) and clicked on "search records" which brought up the Digital Library search screen. The search doesn't appear to be specific to just LowCountry files. Is this correct? --Ronni 11:53, 26 March 2008 (EDT)

Update: after browsing the DL a little more, I can now see that searches on just the specific collections can be done. It would be just a matter of preference what the various organizations would want searched, I assume. --Ronni 11:59, 26 March 2008 (EDT)

Thanks for pointing that out! I've asked them to update the link to point directly to the collection homepage.--Dallan 12:23, 26 March 2008 (EDT)

New Format [29 March 2008]

1. The new background for the digital Library is striking. I found the color contrast a little jarring, but workable. I'll also note that the font color does work with the basic black background---as opposed to the commonly selected, and virtually unreadable, "red against black". I see the main advantage of this choice as making items in the digital library standout/distinguish themselves from other items in WeRelate. A light grey shade for the background might work better, but I'm only one person, and others may find this not as jarring as I do. You might want to ask others how they feel about the color contrast.

For the next couple of months, the entire digital library will use a skin that the LowcountryAfricana.com folks created. The reason is that we don't have the ability to switch between different skins right now, and Lowcountry launched their website yesterday. Eventually we'll create a regular WeRelate skin, and the Lowcountry skin will be used only when the people visit the digital library from the Lowcountry website to search Lowcountry's collection. The idea is to allow any organization to provide a custom skin that will be applied when people visit the library from the organization's website and search the organization's collection, and to use the WeRelate skin when people visit the digital library from WeRelate.

But speaking of the background, I don't know how prevasive this is, but in one record I checked to look at the full meta data table:

http://www.werelate.org/dlib/handle/127?mode=full&submit_simple=Show+item+details

The font color had not been changed, so the text appeared black on black, and could only be viewed by highlighting the area where I thought the real text lay.

The skin had a number of bugs like this initially. I believe they've all been fixed now.

2. I did a bit of testing on the search function http://www.werelate.org/dlib/

a. The Search and the Browse functions are now clearly separated, and distinct.

b. I tried various searches

i. "Name". I assumed this was the "name of the item" but perhaps its meant to be a person's name. In any case I searched for the item

Letter from Smith to Preston, March 22, 1774

The exact title of the aritcle produced no results---or rather found nothing. Searching for "Letter" and "letter from" found nothing However, searching for "Smith to Preston" "Smith" or "Preston" produced appropriate hits.

I take it that the search function simply parses the search string based on where spaces appear. Thus the phrase "Smith to Preston" contained in the title and inserted into the search field, resulted in a search on

name:Smith

name:to

and

name:Preston

returning any item that contained any of the above. "Smith" alone got substantial hits, as would be expected. "Smith Preston" got only the single recorded noted above. From this I note that the search name function a). really is searching for names

b). is searching for both of the the items listed, as long as somewhere they are designated as "Names"

c) is doing an "A" AND "B" search, not "A" or "B". For example, if I had it search" "Jimmy" "Lucy" " it returned a particular record. It would pick up that record if I searched just "Jimmy" or just "Lucy", but would return nothing if I searched " "Jimmy" "Lucretia" "

d) It doesn't seem to take into account Quotation marks, and Boolean operators cause a failure. ("Invalid Search String" message)

I image that implementing boolean searches is something of a hassle, and can understand why at this point its not included. If you ever do implement Boolean searches, the set up on Google is the best I've run across. Decidedly superiod presentation for the average user.

Q 11:52, 28 March 2008 (EDT)

When you submit an item, there is a field where you can enter the names of the people mentioned in the item and another field where you can enter the places associated with the document. Name and Place search those two fields respectively. The third line, Keywords, searches everything - including the textual content of submitted items, the item title, and all metadata fields. (Yes, AND is the default boolean operator if you enter multiple words, not OR.) You can enter quite complex searches in the Keywords field: e.g., name:Smith AND NOT name:Preston to get items for people named Smith but not including people named Preston, or name:"Preston, William" to get items for people named William Preston, or name:Preston OR name:Smith to get items for Preston or Smith. But yes, I like Google's syntax better. I'll be switching over to something more like that eventually.

I just checked, and you can enter "Preston, William" into the Name field to search for items with someone named William Preston.

None of this is documented however; I need to add this to the documentation on Search.

PDF documents [31 March 2008]

I'd like to get Dallan's opinion on something related to downloading documents to the Digital Library. There are a number of sources where copies of entire text's can be downloaded---e.g., Google Books. Many of those works are out of copyright, are were scanned in by Google Books themselves, rather than a third party, such as a publisher. Since the works are out of copyright, I presume that someone might wish to down load one of these scans to the Digital Library. An example of this would be source:Thwaites and Kellogg, 1905, whose contents is largely an extraction out of the Draper MSC. I believe Google places some restrictions on using items like this, but a quick check of Google Books didn't seem to show a "terms and conditions of use" link. I did find a link that showed how you could link to specific works in their digital library.

When I create a source card for a particular reference, I'll often give it a link to an online version. This is usually sufficient for my purposes, but I can think of some reasons why it might be desirable to have a PDF version incorporated directly into the Digital Library. I'm pretty sure you couldn't do this with a work in Ancesry's digital library, as you'd almost certainly run afoul of their restrictive license. But if its correct that Google Books has not enplaced such a license, is downloading and re-uploading one of their files to the Digital Library appropriate?

Personally, I'd rather upload snippets of those works, rather than the whole thing, as then it would be a lot easier to direct someone to the specific passage in question. But even here there may be some question, since if you upload enough snippets you eventually get the entire work in place---just in bits and pieces. So, what do you think? Q 15:27, 28 March 2008 (EDT)

As long as Google doesn't prohibit this (I haven't checked), I'd be fine with it. I agree with you though -- unless the work was short I'd probably upload just the portion that related to my research and add a link to the full google book in the description field. I might upload entire pages, not just paragraph-snippets. Eventually I plan to add a function so that from the Source page you can see a list of all digital library items for the source, so it will be easy to see if the pages you're interested in have been uploaded already.

If you do decide to upload a PDF document, please let me know if the contents are searchable (using the Keywords field). They're supposed to be, but I haven't tested this.

I will create something as a PDF, though I think JRM has added one himself. I'll try searching that. Q 09:38, 30 March 2008 (EDT)

The capacity to add something in a variety of file formats is probably a good thing, but may be potentially limiting for some users. What if you don't have the specific software needed to read a file that you've downloaded. That, of course, is what PDF is about. And PDF readers are going to be much more universal than something like Word. (Understand, by the way, that the next genration of world may be in a "universal" format so that files can be handled by other systems besides word. The downside I read, was that it would not be backwards compatible to earlier versions of Word. Q 09:38, 30 March 2008 (EDT)

I've checked one of JRM's PDF submission to the DigitalLibrary (a cemetery book). I downloaded the item itself, and find that its the entire document, prepared in 2004, and downloaded with a requirement to cite the work. In this case, at least, it was in fact searchable. I was able to locate things fairly easily. I know that PDF files can be created with different capabilities in place. For example, you can lock the PDF so that portions of it can not be copied. That wasn't done here, as I was able to select a portion of the text and copy and paste, viz:

Sumner D. Marden M.D. 1852–1885 Concord, N.H.

Annie M. (Maria Woodman) Marden 1864-1933

I don't know if there's something that would "lock down" the search function, and that doesn't seem likely. But I don't use PDF's files that much myself and am not familiar with the in's and outs of what you can and can not do in limiting folks use of the document. But in this case, the search function worked fine. Q 10:34, 30 March 2008 (EDT)

This example, by the way seems to be an instance where you probably wouldn't want to bother with extracting a snippet from the original, and place the snippet in the DL. While the work is quite long (135 pages), its main value is probably best served by leaving the document intact, and the snippets would probably be so small as to do good only for a single use. Q 10:46, 30 March 2008 (EDT)

Thanks! The text of the PDF is also searchable from within the digital library, so if you enter "Marden Cemetery" in the Keywords field of the digital library search form, this document comes up. I agree that this is a case where the entire document ought to be uploaded.--Dallan 10:48, 31 March 2008 (EDT)

Collection Banner [29 March 2008]

The banner now displaying on each collection page is attactive. The WeRelated Logo looks good against the black background. The Africana logo also looks good (elegant might be the word), However,

a) It's appearing on the page of each collections, not just the Low Country Africana Collection it was designed for. I presume that's because you do not currently have logo's for each collection

b) I'll work on a banner logo display for SWVP. (I assume these can be changed at will. The one I have in mind isn't quite right, but until I can find a better display it is probably the best I can do.

c) The logo for Low Country Africana Collection needs to be offset to the left so that the search box does not overlap it. Not strictly necessary, but the design does not work well with a cookie cutter hole in it, I think.

Looks like you've taken out the "WeRelate" logo, and the search box from the banner for collections, etc. Also looks good, and this eliminates the problem with the overlap of the Collection Logo with the search box----though you might want to consider reinserting the WeRelate Logo on the left. Against the black background it really did look good---and nicely branded the Digital Library to WeRelate. Q 08:30, 29 March 2008 (EDT)

(Now that I can see the full data display for these pages, as it was meant to be seen I like the White on Black presentation more; Clearly distinguishes Digital Library pages from the main WeRelate.)

I've noticed a few disconnections in the work flow. Since this is just going up, it may be better for me to let you get all in place, rather than poking at something that's changing and being added to simultaneous with my poking.

Q 19:41, 28 March 2008 (EDT)

Yes, eventually we'll put the Lowcountry logo on just the Lowcountry collection. I'm not all that wild about the white-on-black skin, but it fits with the rest of LowcountryAfricana.com. Once the digital library is integrated with the rest of WeRelate in June, it will adopt the WeRelate skin, except for people visiting it from Lowcountry who will continue to see their skin when searching/browsing within their collection. The goal with the digital library is to provide free hosting for any project or society that wants to use it, and we'll try to accommodate their skin preferences. I need to add the capability to change between different skins for that to happen.

Also, I spent the last couple of days focusing on searching and browsing items in preparation for the Lowcountry launch today. It wouldn't surprise me to find out that the submission process has suffered a bit due to the new skin. I'll look at this early next week.

File Names and Descriptions [29 March 2008]

http://www.werelate.org/dlib/handle/210?mode=simple&submit_simple=Show+summary

I submitted a file with the title "Daniel Smith's Company Roster, 13 Aug 1774.jpg" The title was fairly descriptive, and so that's what I put into the "description field", but when I look at the resulting card, this looks pretty redundant. Which prompt's the following:

1. Are there any specific recommendations to be followed with regard to

a. What to name a file submitted to the Digital Library?

b. What information should be placed in the "Description" field?

You didn't ask this question, but I'd like to suggest that people begin the item title with the name of the primary individual (surname, given names) mentioned in the item. So "Smith, Daniel, Company Roster, 13 Aug 1774" might be the item title. That's a nice format for people browsing items. Regarding the Filename, I don't think it matters much what the filename is called. And unless you're uploading more than one file, I'd leave the File Description field blank. If you're uploading multiple files, you might give them descriptive filenames or descriptions like "left-hand-page", "right-hand-page", "page 29", etc.

2. The mechanism for uploading images into WeRelate includes a capability for nameing the file something different from what the system finds on your computer. This is probably a bit handier than the system used in the digital library where you have to get the name of the file right before you upload. This is particularly the case if its a screenshot (with a title like "Screenshot 6"---not something you'd want to see in the Digital Library.

I don't think it matters -- you would use the Item Title to provide a descriptive title, wouldn't you? And in the case where you're uploading multiple files for an item, would you use the File Description field to describe each file?

3. It might also be handy to be able to rename a file that's been uploaded, but that may not be with the capabilities of the current MediaWiki.

It would be handy to rename Images uploaded to the wiki, but it appears to be a fair amount of work to extend the MediaWiki software to allow that.

4. I note that the term "description" is used in two different ways on the cited page.

a. First, its whatever you put in the key words field during the submission process b. Second, its a descriptive phrase that you're asked for elsewhere n the process.

Either the terms used need to be made distinctive, or the same thing needs to go into both places---not recommended since that would be redundant. What would probably work best would be to rename the first "Description" field to "Key Words".

By the way, when you enter key words, are they litterally key "Words" (space deliimited), or are these comma delimited phrases? Perhaps that should be made clear when you'r asked for "Key words".

21:26, 28 March 2008 (EDT)

There's an item description field that's labeled "Description / Keywords", and a description for each uploaded file that I think is labeled "File Description". Is that what you're referring to? The item description is searchable along with all of the other fields you enter when uploading an item by using the Keywords field on the search form. If I were uploading an item to the library, I might use the item description field to give a quick summary of the item -- additional information about the item that's not contained in the item title. I'm not sure what you mean by whether it's contents are searchable as space-delimited words (they are), or as comma-delimited phrases (you can do phrase searches using quotes, but comma placement is ignored). It's as if you had a web page with the item description on it and someone were to use Google to search for your webpage.

I'm not sure what would be best to call the field. I like to think of it as a short description of the record, but it could also be used for placing keywords that would be searchable. For example, Lowcountry wants to track occupations of the people listed in the records. I removed the "Occupation" field, so they're tracking occupation in the Description/Keywords field.

Recommend this item and metadata [31 March 2008]

http://www.werelate.org/dlib/handle/210?mode=simple&submit_simple=Show+summary

Tested the "Recommend this item". Sent myself an email using this function. It worked fine.

You may want to consider changing the name of the link to something like "Send this to a friend", as more closely matching the intent. "Recommend this item" might be misconstrued as meaning to evaluate its quality in someway.

Good point. I'll change it.

The email included the handle for the item. (viz Location: http://www.werelate.org/dlib/handle/210 in the example I used. However, when you clearned up the metadata labels, the "Handle" element seems to have dissappeared. Its obviously still there in the database, just not displaying with the rest of the meta data. Since its potentially handy for inserting links into articles, it might be good to restore it.

Someone else said they got confused because when they clicked on the handle field, they were taken back to the same page, so I took it out. It's still in the URL field of the browser. Rather than displaying the URL in the metadata, I was actually thinking that once we integrated the digital library and the wiki, that I'd make [[dlib:210]] a link to the item, and that I'd display that text instead of the full URL. What do you think? (I could do that now if it would help you -- it's easy to do.) I could also re-display the Handle field and just not make it clickable. That might solve the clicking problem.

I probably said something like that myself. Perhaps the solution might be to make the link "non-clickable"---since it takes you immediately to the same page. The form [[dlib:210]] looks like it would be quite handy. Also like the compactness---and less to remember. However, the full URL does now take you from somewhere else to the DLIB page. Using that form people can start connecting information now. [[dlib:210]] would be handier in the long run, but there probably should be a copy of the de-activated url in the meta-data. Q 09:22, 30 March 2008 (EDT)

I'll put the URL back.--Dallan 10:48, 31 March 2008 (EDT)

Q 21:44, 28 March 2008 (EDT)

Links to Source Pages [31 March 2008]

Elsewhere Dallan has suggested that linkage to source pages may become optional. This would simplify some problems---for example, if someone had an original document that did not appear in published source, you would be left with nothing to pin it to. So this suggestion would make that a bit easier to handle, since they wouldn't necessarily be stopped by the lack of a source card on WeRelate.

However, there are other ways to solve the problem. What you might do in these circumstances would be to create a Source Card for the specific document as a standalone item. That Source card could then contain all of the information others needed to evaluate the item, or conceivably locate the original. If you don't do something like that, then perhaps there needs to be something included in the Digital Library entry to show where the document could be found and recovered if need be.

A type of problem that I'm seeing is that the card for an item in the digital library may not be providing enough information about exactly where in a source a particular item was found. Since the Source card that its pinned to is being seen as a collection of items (e.g., a specific document that's found in something like Source:Thwaites and Kellogg, 1905), citing the source card doesn't tell you exactly where in the source the material would be found. I believe when I filled in the data for some items one of the fields included things like volume and page number. This does not seem to be displayed in the metadata, and should be. Otherwise, you can find exactly where in a document something was found. Q 09:16, 29 March 2008 (EDT)

Hmm, Volume and Page number should be displayed in the item metadata. I thought I'd verified this. Please let me know if it's not.

Its not currently in this example. http://www.werelate.org/dlib/handle/210?mode=simple&submit_simple=Show+summary Would it fail to show if the field were empty?

Yes, empty fields don't show. I could change that, but it does result in a less-complex page to not show them.--Dallan 10:48, 31 March 2008 (EDT)

I've been thinking along these lines as well and I'm planning to add two additional fields to digital library items: Repository, and Location within Repository. The Repository field would be used to name the online or offline repository where you found the item, and Location within Repository would be a place where you could tell someone where to find the item in the repository: call number, URL, etc. Would the addition of these two fields (and showing Volume and Page number) be enough to address the problem?--Dallan 23:58, 29 March 2008 (EDT)

That would be good. However, there are other conventions in use besides Volume and Page. For example, the Draper MSC uses a complex file folder designation---something like QQNN13---which has its own locational logic related to their system of files and folders. You can't anticipate EVERY possibility known to man, or conceivable by the mind of man, so perhaps what is needed is a less explict name that can be applied so that people wouldn't feel that they a) had to put in Volume and Page, b) could put in whatever was appropriate. "Location Within Source (e.g., page, volume, or other descriptor" would be kind of cumbersome, but would convey the right guidance. Just need something shorter. Perhaps 'Location Within Source" with an explanatory link to an explanation. Q 09:31, 30 March 2008 (EDT)

That sounds good to me. I'll replace volume and page number with "Location within Source".--Dallan 10:48, 31 March 2008 (EDT)

Submit:Verfy Submission [1 April 2008]

http://www.werelate.org/dlib/submit

Text in the upper left reads:

Submit: Verify Submission

Not quite there yet, but nearly!

Please spend a few minutes to examine what you've just submitted below. If anything is wrong, please go back and correct it by...

recommend different phrasing for last line as a) the first sentence of which ends in a preposition, and b) the information hasn't been submitted just yet so "just submitted may be a bit imprecise. Perhaps

Please spend a few minutes to examine the information you have provided for this record. If anything is wrong, please go back and correct it by...

That's good. I'll change it.

Q 13:18, 31 March 2008 (EDT)

Submit Upload File [1 April 2008]

http://www.werelate.org/dlib/submit#null

1. Text reads:

Please give a brief description of the contents of this file, for example "Main article", or "Experiment data readings".

The examples look like leftovers from the underlying software. Something more specific to genealogical purposes would be better. Perhaps this should point toward the basic type of document being stored in the library (e.g., Letter, Manuscript, Book, article.) Q 13:43, 31 March 2008 (EDT)

I missed that one. (There are probably a few others as well; hopefully not too many.)

2. At some point I went to the link "Information about file types and levels of support for each are available." That brought a popup window. After reading that I clicked it off, returning to the upload page. And got "malformed message error" Do not believe I used the back button in any of this, which I know can give this error. used the "Previous" button to leave the page, then returned and problem was corrected. Doesn't seem like one should get an error simply reading the instructions; seems like this should be handled in obtrusively. Q 13:51, 31 March 2008 (EDT)

I'll fix this.

3. During the Submit process you have an opportunity to review the file by clicking the link to the file name. That results in a download of the file, which you can then examine. However, what appears on the screen is a blank browser window. This may be disconcerting to some who are expecting to see the item in the window, rather in their downloads. Q 16:46, 31 March 2008 (EDT)

Thanks. I'll fix this as well.

File modifications [1 April 2008]

I find that I left off part of the material in the file Daniel Smith's Company Roster, 13 Aug 1774.jpg previously submitted to the Digital Library. I'd like to add the missing material as an additional image for this file. Is there someway to do this short of creating an entirely new record? Q 14:21, 31 March 2008 (EDT)

There is, but until I add the item-edit functionality (which will be a couple of months) the only way to do it is through the administration interface. If you email me the file I'll be happy to upload it for you.

Thanks, you have enough to do I suspect. Its not a biggie at the moment. I'll keep a reminder that this is needed when the functionality becomes available. Q 15:27, 1 April 2008 (EDT)

Back Links to We Relate [2 April 2008]

Prior to enabling of the Digital Library I was inserting documents either into MySource or Source articles. That allowed me to create links when I created a Person or other article, such that the reader could easily get back to some of the source materials I was using. This looks like it won't work quite so smoothly once the Digital Library is in place. If I transfer an item (e.g., Source:Pension Statement of James Fraley) to the Digital Library, the document submitted will only be viewable for the user if they download it.

Also, I've been including links to relevant articles into documents that I've loaded into the source namespace. In Frayley's pension statement referenced above I included a link to Moore's Fort when that feature was mentioned in his pension statement.

Will this be the case or is there some other development in mind that would allow items to be displayed in the user's browser? thus making links embedded into items placed in the digital library live? (Alternatively, I could include the full http link, but the source link currently used would be a bit more elegant, and a lot less trouble to insert. Q 18:58, 31 March 2008 (EDT)

This is where uploading items to the digital library isn't going to be as convenient as creating MySource's in the wiki. If you upload a text (.txt) file it should be displayed directly within the browser. Let me know if it's not. (There is a threshold setting that dictates that a download dialog be shown for very large text files, but I can set that threshold higher if needed.) HTML (.html or .htm) should also be displayed directly within the browser. You can include links in the HTML file, but they'd need to be of the full http form.

OK. I've seen something's that have suggested that was how it worked, but didn't pick up on it fully at the time. (I noticed some text appearing in the browser window for one down load, but didn't realize what I was seeing until I clicked off. Then couldn't get the thing to repeat. What I was seeing may have been an articfact of some description, as the downloaded page did have some html in it----just not the HTML ending. Not really sure what was going on here, but I'll play with this somemore. I'll load something into the sandbox to test. I'll check to see if it requires the wiki version of HTML (doubt it), or you have to go full up HTML. (probably---drats. Like wiki better. LOTS easier to use.)

Yes, it's going to require full HTML -- it just displays the file in the browser without any pre-processing.

I have an idea about allowing people to attach annotations to either images or text, where anyone could add annotations, and the annotation would include some text and/or a link to a wiki page - similar to the current Image page annotations. This would allow for example people to annotate an uploaded census image with a link from the region where their ancestor appeared on the image to their ancestor's wiki page. It will be months before this is implemented though. In the meantime (and possibly even afterward), if you want to add a lot of links to the item you're uploading, I'd create it as a MySource or an article.--Dallan 13:26, 1 April 2008 (EDT)

That sounds like it might work. My focus at the moment is trying to see how I can use the Digital Library to support articles on the Wiki---testing out various approaches, seeing what works best, and what doesn't. Q 15:26, 1 April 2008 (EDT)

Please let me know what you find out. We've got a couple of months before the digital library is launched "officially".--Dallan 09:36, 2 April 2008 (EDT)

Links to Digital Library [5 April 2008]

I did some exploration with linking from WeRelate proper to files in the digital Library.

I tested the idea that you could set a file up in HTML format, and get it to display in a browser window. I loaded the source code from one of my existing articles, into a dummy file in the Digital Library Sandbox. Then played with links from the WeRelate Sandbox. Got some interesting (and in some cases slightly unexpected) results. Here's a summary

note the distinctions between tests with "1228" and "242". The "1228", seems to be an index number created immediately upon submission---242 is "after approval". Both indexes work, if you use the right url format. For example,

in test 5 I used "1228 in conjunction with "retrieve" and got the right file

in test 6 I used "242" in conjunction with "handle", and sort of got the right file---it took me to the digtal library card for this file, where I could open the file by clicking the appropriate link.

in test 7 I used "242" in conjunction with "retrieve", and got one of the LowLand Africana submissions.

In the bitstream tests (8 and 9) I played with the switches a bit. Apparently these refer to the image number for a multiple file submission, with "/1" being some sort of place holder.

The form in test 5 (retrieve/1228)seems to work best. This form actually opens the file directly in the browser without any intermediate steps. Not sure at the moment how to get the right index number out of the system.

Also, playing around with different "retrievals" I find that if its not HTML, you get other things, and what you get isn't intuitively obvious. in some cases if the file is an image it shows up as a very tiny (and near useless) thumbnail, but in other cases it shows up as a full scale radable image. Sometimes you get a statement of about who authorized the file, and under what kind of license. Sometimes you get a statement that you aren't authorized to do that. (I think that occurs in some intances when you are crossing over into a different collection---but not always. So there's more going on here than is apparent at first glance.

Q 13:47, 2 April 2008 (EDT)

I think my preference would be to link to the items e.g., http://www.werelate.org/dlib/handle/242. This way people can view the information you have uploaded about the item (e.g., item title, description). If you link to the bitstream directly there's no way for them to go from the bitstream to the information you uploaded about the bitstream.

If you do want to link directly to the bitstream, using http://www.werelate.org/dlib/bitstream/242/2/HTML_TEST.html works. The "/retrieve/nnnn" URL refers to an internal ID for the bitstream. In order for you to find out what the internal ID for a bitstream is once its been uploaded, I'd need to add it to the item display screen. Is there a good reason to want to link to the bitstream directly instead of linking to the item page?--Dallan 16:22, 3 April 2008 (EDT)

I sort of figured the retrieve/1228 was a bit of internal indexing, and only incidentally available. Since you can get there with a bitstream pointer, it seems superfluous to bother with the retrieve code.

There is a reason why you might want to use the bitstream as opposed to the handle. One of the ways I've thought of using the digital library is to bring up a particular item in a separate window. Thus, when you were reading an article about XYZ, and there was a link to an item related to that in the digital archive, you could bring up the article itself and examine it, while the referring article was still visible on the screen. Then the reader could examine the article, while still seeing the source material side byside for purposes of comparison. Yes, you could still do that by clicking the link on the metadata page, but this would be a lot more elegant, and less distractive to the reader. Its a technique I can see being used very effectively by an author willing to do the needed coding. Q 16:38, 3 April 2008 (EDT)

After exploring this some more I see I managed to mislead myself. When you go to the metadata page for an item in the digital library, and click the link to the itemself, it will (depending on the type of item) open in a new window---which is the effect I want, but I don't want to have to interupt the information flow by forcing folks to go to the metadata page, and then figure out how to get the item to display. I'd like to see that happen immediately. (This is the "Don't confuse folks with needless detail" approach to information flow.) But the way this is set up you can't actually use either the "handle", "bitstream" or "retrieve" code to get this to happen. Placeing ANY of those code's in an article only opens the image in the same browser window, not a new browser window, or worse, takes you to the metadata page.

For article creation I think this would be a very useful approach, if it could be made to work. But I've no idea how difficult it would be to create such a capability. I thought the "retrieve" code would do it, but apparently even that does not do the job. So, any suggestions? Q 09:00, 4 April 2008 (EDT)

Try <wr_a>URL|text|_blank</wr_a> (example). This is a pretty advanced feature and I haven't documented it yet.--Dallan 11:53, 4 April 2008 (EDT)

Perfect! Tested it and it did exactly what was needed. I can think of a number of applications for this, not necessarily related to the Digital Library. For example, you could do pop up windows for a list of references, or perhaps for more complex explanations of something, such as the following this list of alternative bibliographic citations

Placeing it into the Digital Library might work better, as that would focus the display on the part that you wanted to emphasize, rather than the window dressing of a standard page.

Same thing but placed in DL

Tried that as a 'txt' file, and forgot that the formating wouldn't transfer. Perhaps HTML would do it better, but clearly the capability to do this kind of thing is in place. Q 12:56, 4 April 2008 (EDT)

Zotero [3 April 2008]

I've been playing around with Zotero (a Firefox extension) a little more the last few weeks and just thought I would mention that it's able to capture citation data from the Digital Library. It's actually quite neat. It also can capture data from Wikipedia (for instance an article that has reference citations). --Ronni 13:39, 2 April 2008 (EDT)

I agree - Zotero is neat!--Dallan 16:22, 3 April 2008 (EDT)

Images and pictures [5 April 2008]

Suppose one had a family photograph that they wanted to use to support a person article. Normally, this would go into image namespace, but at least in theory, one could put it into the Digital Archives as well. This would might create a problem since there would probably be no supporting article to pin the image to as a source. Dallan has said that he might make this optional. If having a "source" card to pin the photograph to became optional I don't know how you could prevent people from putting a family photograph into the digital archives. I'm not in favor of having a "rule" to cover every contingency, but perhaps some thought should be given as to whether the digital library is also to become a repository for family photographs. Having two places for the same thing seems untidy. Eventually, what may be needed is a guidance page to indicate to the users what properly belongs in the Digital Library, vice Image namespace, vice person and article names space, etc. Q 20:30, 2 April 2008 (EDT)

My initial thoughts are if you're just uploading a single photograph, you should upload it as an Image since you can embed images in wiki pages. But if you're uploading your entire collection of 100 photographs and you don't intend to embed them in wiki pages, you might want to upload the collection to the digital library (ideally as a single ZIP file which we would then expand into separate bistreams for each photograph).--Dallan 16:22, 3 April 2008 (EDT)

I'll explore that and see how it might work. Q 16:39, 3 April 2008 (EDT)

Working Example of "Pop Up" [15 April 2008]

There are several instances where I've felt a need for a "Pop" up style window to show/amplify certain points. An example is in the map of the forts of Southwest Virginia. The main article for this map is at List of Forts of Southwest Virginia. This article gives a list of the forts, but the map that accompanies the article (Map_of_Forts_of_Southwest_Virginia._1 is too large to display on the same page as the tabular list. (If you put them both on the same page you get whip-lash scrolling from one to the other).

The solution to that is to use the coding that Dallan pointed to in one of the above topics. This coding can be used to open an item in a separate window while keeping the main window open. Thus I can have the map on one page, and the index on another page, and you can examine them both simultaneous. I've added this to the map page,

Map of Forts of Southwest Virginia. 1

and you can now bring up the list specific to this map by clicking the appropriate link on that page.

To make this work effectively I had to place a subset of the index from the main article into an HTML file stored in the Digital Library. The metadata for that file can be seen at [1]. Then I used the bitstream code http://www.werelate.org/dlib/bitstream/260/2/Index%20to%20Forts%20of%20Southwest%20Virginia.html) to link to the actual file. The advantage with doing it this way is that you get the "popup" window effect without having to pass through the metadata page.

The main problem that I see with this at the moment is that the popup window occupies most of my screen, and obscures the page from which it was called. this would be more effective with a small size popup window. I don't know if there's a convenient fix for that--perhaps something placed in the HTML coding would do that, but I don't know.

I should probably add that strictly speaking you don't have to go through the digital library to make this trick work. You can link to any WeRelate page, getting it to appear in a separate window, with the same basic code. The advantage of going through the digital library is that you can exclude the "window dressing" (ads, formal WeRelate layout features, etc) and just display the intended content of the popup. That way you can focus the readers attention on what you want to show him, rather than distracting him with unneeded details. One of my overall objectives in writing is to attempt to make the information transfer from the page to the reader as direct as possible. So ultimately, I want to get rid of things that aren't conducive to that goal. This is one way of doing that.

Note that this will work only with certain types of files in the Digital Library. It will work, for example, with html files, txt files, and images, but not with pdf's or things like WORD documents. The advantage of using an HTML file, as opposed to say an image or a txt file, is that HTML permits you to format the layout of the display, and any live links are preserved. (Note that the blue links in the popup are in fact live links, and will take you to articles about the individual forts.

Q 09:44, 5 April 2008 (EDT)

It would seem that this no longer works. Is there anyway to get this capability restored, or is this something you would prefer not to have available. Thanks Q 11:34, 12 April 2008 (EDT)

It should still work - I haven't knowingly done anything lately to break it. I just went to Map of Forts of Southwest Virginia. 1 and clicked on the index link and it opened up in a new tab for me. (I'm using firefox so new windows open up in tabs.) what happens when you click on the "index" link? If it's opening up the index in a new tab instead of a new window, and you've recently started using a tab-based browser like IE7 or Firefox, and you'd rather have it always open up in a new window instead of a tab, let me know. That wouldn't be too hard to fix.--Dallan 18:31, 15 April 2008 (EDT)

HTML Template [15 April 2008]

I spent some time this morning on setting up an HTML template header to be used to format items that are intended to be displayed in a browser window. I inserted a bit of header material into a txt file

[2]

Since this is a txt file, you should be able to see the actual HTML code when you go to the above link.

This can be called up from the library, the code copied, and inserted into a file intended to contain the desired item. The layout set up is for a two column Table, but templates for other display layouts could be easily created. I've included a component into the table asking for some basic information about the item, including

a) a Title for it b) the source where it was obtained c) the source for the original record (not necessarily the same as where someone obtains an item.

An example of its use can be found at [3]

Suggestions for modifications, particular with regard to unneeded components of the code, or additional components that could be useful, would be appreciated.

Q 11:14, 12 April 2008 (EDT)

Interesting - I can't access the "retrieve" URL for the Generic HTML Template unless I log in. Accessing the "bitstream" URL doesn't require me to log in though. Another reason to use bitstream URLs instead of retrieve URLs.

You could simplify your header considerably if you wanted. Most of the lines in the "head" section are links to stylesheets and javascript files that you don't need to display an index table.--Dallan 18:31, 15 April 2008 (EDT)

<html> <head> <title>Title goes here</title> </head> <body> <table border=3> <tr bgcolor=lightgrey><td>Entry Type<td>Entry <tr><td bgcolor=lightgrey>Title:<td> <tr><td bgcolor=lightgrey>Immediate Source:<td> <tr><td bgcolor=lightgrey>Original Source: <td> <tr><td bgcolor=lightgrey>Item:<td> </table> </body> </html>

Large Loads [21 April 2008]

I recently attempted to load a series of sound files using the "Add File" function. This was very very sluggish. And the more files I added, the more sluggish it became, until it reached the point where it was unworkable. I'm going to assume that this was a function of adding lots of largish files. Don't know if the individual sound files were particular large, but things definitely slowed down. I explore this a bit more and see if large number of image files do the same thing. Q 11:25, 21 April 2008 (EDT)

List of Submissions [4 May 2008]

In checking some things on the Digital library I looked at the list of submissions included under my user name. There were only three items, though I've submitted many more than that. When I check the Southwest Virginia Project collection I find the missing items. Apparently things submitted to a collection do not get swept up when a person looks for submissions under their user name. Seems like people would want to look at their submissions as a whole. The current arrangement would be fairly inconvenient when more than one person is adding to specific collections. Q 09:13, 4 May 2008 (EDT)

I've come to the same conclusion. It seems that we'd want to add all of your submissions to your "watchlist" somehow.--Dallan 14:02, 6 May 2008 (EDT)

Family Exchanges and collections in the Digital library [29 November 2008]

I am mulling over how to best store digital images from the [Coleman Family Exchange]. For example, I could create a community entitled Coleman Family Exchange. I could start with one collection entitled Coleman Death Certificates and upload images when received. On the actual web page; I could enter the text and I assume that I could create a link to the image from the web page.

However, is this going to create more work for me and not enough time to finish my other projects? Will this make it too difficult for contributors to add data? Opinions. --Beth 11:08, 14 June 2008 (EDT)

This page somehow escaped my attention. Sorry for the (really) late replies. Also, as you can probably guess, with everything else going on right now the digital library probably won't going to be integrated into the rest of WeRelate until mid-2009.

In answer to this question, if you want others to be able to comment on the picture I'd add it to the wiki; otherwise add it to the digital library.--Dallan 20:20, 29 November 2008 (EST)

Large PDF [5 July 2008]

I have a large PDF (approaching 10MB)---its a pension application in PDF format, using images of the application. Is this too large for the Digital Library to handle? Q 22:02, 5 July 2008 (EDT)

No. The thing to worry about with large items is more how long it would take someone to download it. So while a 10MB item could be stored without a problem, you might want to consider breaking items this large or larger into two or more smaller files so they can be downloaded individually. It's not a requirement though.--Dallan 20:20, 29 November 2008 (EST)

Date of Issue [29 November 2008]

at http://www.werelate.org/dlib/submit "Describe" Asks for "Date of Issue"

a. Not sure "Date of Issue" is the correct term. Some items, like a letter might have a "written date", but date of issue implies something else---as in the date an document was published. Publication date might be better, but letters aren't exactly published. So maybe simply "Date" would be best. Either that or develop an explanation as to what "Date of Issue" refers to.

b. Pull down menu asks for the "No. Month", but the menu list gives abbreviations of the names of the month, not a choice of month numbers.

at http://www.werelate.org/dlib/submit " "Submission Complete" a link is needed to take you to the document just completed. That way you can conveniently caputre the appropriate URL for inclusion into an article. Alternatively, a link back to the list of recently completed submissions would do.

--Q 10:48, 9 September 2008 (EDT)

These are good suggestions -thanks!--Dallan 20:20, 29 November 2008 (EST)

Date of Issue [6 April 2009]

Under "Describe"

You ask for "date of Issue" described as "Please give the date of publication or the date the record was made. (You can leave out the day and/or month if they aren't applicable.)"

Some clarification may be in order.

I'm adding an indenture written on 19 May of 1782, but not recorded in the county Clerk's office Deedbook until 20 August 1782 Its not clear which date should be entered. The date the indenture was made, or the date it was recorded? Q 07:30, 4 April 2009 (EDT)

Good question. I don't have a strong opinion about this case. Any thoughts?--Dallan 11:02, 6 April 2009 (EDT)

Only that I run into this in other contexts as well. For example, a record is recorded in a county document in 1782, indicating that a certain event happened in 1775. And its the 1775 date that's of interest for most purposes. Which date gets put down? Not sure there's a good solution for this kind of thing. Formally, I would have to say its the date of the recorded. But often, the critical information is when the event happened. Perhaps what's needed is a clarification---"Date of Record" and "Date of Event"? This probably happens a lot in wills, where there's a probate date and the date the will was written. Q 13:29, 6 April 2009 (EDT)

To keep it consistent with other uses of the field (i.e., date published for a book or magazine), perhaps the "date of record" semantics should be preferred.--Dallan 13:52, 6 April 2009 (EDT)

Tangible Form [12 May 2009]

The cpyright section of the DL has the statement withregard to copyrighting of family papers etc

(sharing something with close family members is not publication; putting it in a newspaper is)

I believe the copyright law only requires that something have been placed in "fixed tangible form" and that constitutes publication--even if its distributed nowhere at all. Thus a family letter written in 1850 would have been placed in fixed tangible form the minute it was written. Even if it were never mailed, or seen by anyone other than the author.

Q 10:44, 12 May 2009 (EDT)