LOGOS: Your recent response to Metadata Tagging Proposals

Page 1 of 3 (42 items) 1 2 3 Next >
This post has 41 Replies | 3 Followers

Posts 25276
Forum MVP
Dave Hooton | Forum Activity | Posted: Sun, May 16 2010 8:06 PM

I just noticed a recent response at http://wiki.logos.com/Metadata_correction_proposals

Response 1

  • All Lexicons should have appropriate ancient language as well as lang:English
    • The language of a book is the primary language it is written in rather than the language it is about, so a Hebrew lexicon written in English is English, not Hebrew. A Greek grammar written in Spanish is Spanish, not Greek, etc.

The proposal was intended to distinguish Greek lexicons from Hebrew, Aramaic and other ancient languages but also to help distinguish lexicons from other resources of type:dictionary and from English dictionaries like Merriam-Webster, Oxford Concise.  It seems arcane that these should all have language English.

However, the response is inadequate because the proposal is at least 5 months old and no alternative is given. It does not recognise the need or purpose of the proposal. If the alternative is to use the 'language xxxx' in Subjects then this should have been stated. Note that  this field needs attention as language is not supplied for at least 7 of my lexicons (do I have to list these?).

Response 2

  • Bible commentaries vs Bible notes: Resources that comment on every verse of the Bible should be tagged as commentaries, those that comment briefly on some verses only, or which title themselves “Study Bible” should be tagged bible-notes.
    • Logos’ use of these types is primarily functional rather than descriptive. The Commentary type is used for many different kinds of resources that are indexed by Bible verse and that the user may want to appear in the Passage Guide. Bible Notes are used for the Notes from a Bible, as, for instance, most of our “Study Bible” resources. Further breakdown of the Commentary category would be somewhat arbitrary, so it’s better left to user discretion via tags.

This response does not recognise a need that has been widely discussed for many years and is just as applicable to L4 as it was to L3. To illustrate its inadequacy my library contains 5 Bible Notes of which 3 have the title "Study Bible" and my commentaries (type:Bible Commentary) include 7 with the title "Study Bible"! Who makes the decision that "the user may want to appear in the Passage Guide"? Is Logos listening?

 

Background

This wiki article has been used to document requests for changes to Logos' resource metadata and for Logos to respond to these proposals. It has been fairly successful but changes have been slow.

Usage

The primary reason to change metadata is to create efficient dynamic collections with criteria like type:bible lang:English rating:>1  but also to ensure Logos4's internal categorisations are correct for prioritisation and guides.

Dave
===

Windows 10 & Android 8

Posts 13379
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, May 17 2010 1:59 AM

Dave Hooton:
The language of a book is the primary language it is written in rather than the language it is about, so a Hebrew lexicon written in English is English, not Hebrew. A Greek grammar written in Spanish is Spanish, not Greek, etc.

Dave is absolutely right - this is an inadequate response for the following reasons:

  • The languages field is designed to hold multiple languages (even the library calls it "Languages", not "Language"). So it's wrong to say the language of a book is the primary language it is written in.
  • Several lexicons already have two-three languages entered, including:
    • Tense, Voice, Mood (Larry Pierce)
    • Abridged Kittlel
    • Liddel's Intermediate
    • Abridged Brown-Driver-Briggs
  • There is a really obvious need to create collections of say Greek lexicons. The language field is the obvious way to do it. Try creating a dynamic collection for Aramaic lexicons and then tell me we don't need 'Aramaic' in the language field.
  • There's absolutely no logical reason I can see not to do this.

Please, Logos, reconsider.

 

Posts 13379
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, May 17 2010 4:49 AM

As a further follow up, Logos said this:

Logos:
“Ancient manuscript” is reserved for transcriptions of ancient manuscripts. Translations don’t fall into this category.

But the following are both tagged as "Ancient manuscript"!

  • The Dead Sea Scrolls: Study Edition (Translations)
  • The Nag Hammadi Library in English

I think these are rightly tagged in this way, but it's clear the tagging isn't consistent again.

P.S. I've invited Louis St. Hilaire to the discussion, as I think he's the person at Logos who's responsible for these decisions.

Posts 489
LogosEmployee
Louis St. Hilaire | Forum Activity | Replied: Mon, May 17 2010 11:14 AM

My apologies for the slow response on many of the correction proposals. As we've done some hiring in Text Development and we continue to work out the kinks out of the system on our end, I'm hopeful that we'll be addressing another good-sized chunk of them soon.

Some of the difficulty here is that, while many of these metadata fields are transparently accessible to the user for the first time in Logos 4, they already have a long history with functional implications for how books are processed and how the software uses them, so user collections are not the only concern. In addition, as is obvious, we've often not been very successful at maintaining consistency over the years and between thousands of resources, leaving users guessing as to what our intentions are for the different fields now that they're plainly visible.

Dave Hooten:
The proposal was intended to distinguish Greek lexicons from Hebrew, Aramaic and other ancient languages but also to help distinguish lexicons from other resources of type:dictionary and from English dictionaries like Merriam-Webster, Oxford Concise.  It seems arcane that these should all have language English.

However, the response is inadequate because the proposal is at least 5 months old and no alternative is given. It does not recognise the need or purpose of the proposal. If the alternative is to use the 'language xxxx' in Subjects then this should have been stated. Note that  this field needs attention as language is not supplied for at least 7 of my lexicons (do I have to list these?).

We are actually planning to split the dictionary type into a few more types that will be more specific. Once we've sorted through the category and are ready to launch the changes, we'll make an announcement with complete details so that you can adjust your collections accordingly.

Using subjects for this purpose would be more appropriate. When we make the change to the dictionary types, we'll also make sure we have consistency in the subjects to make this easier.

Dave Hooten:
This response does not recognise a need that has been widely discussed for many years and is just as applicable to L4 as it was to L3. To illustrate its inadequacy my library contains 5 Bible Notes of which 3 have the title "Study Bible" and my commentaries (type:Bible Commentary) include 7 with the title "Study Bible"! Who makes the decision that "the user may want to appear in the Passage Guide"? Is Logos listening?

Right. Our use of "Bible Notes" has been terribly inconsistent to the point that you can't really force it into a pattern. I ought to have been more clear that this is an attempt to provide a simpler definition that requires corrections on our end to implement rather than an explanation of things as they stand.

As for "who decides", my intent was to say that simple and broad categories leave us with fewer arbitrary judgments to make between types of books organized and indexed by Bible verse, which leads to more straighforward behavior within the software for such books and more flexibility for the user to categorize and prioritize what shows up in his Passage Guide. (Also, just to be clear, both "Bible Notes" and "Commentary" show up in the Passage Guide, so this particular distinction doesn't affect that function.)

Mark Barnes:
But the following are both tagged as "Ancient manuscript"!

Yes. There are a couple of cases where this type was mistakenly used for translations. These will be corrected to conform to the standard use which has been applied everywhere else.

Anyway, even though we've been slow to respond--and not able to change everything--please keep the proposals coming. Dynamic collections open up a lot of new possibilities for using of our metadata, which weren't necessarily envisioned in the past, but which can be very powerful. Knowing how you're using them--and how you wish you could use them--helps us improve the system.

Posts 1646
SteveF | Forum Activity | Replied: Mon, May 17 2010 11:48 AM

Dear Louis St. HIlaire:

Thanks so much for your response to Dave and Mark.

My only "quibble" might be with the following statement.

Louis St. Hilaire:
many of these metadata fields are transparently accessible to the user for the first time in Logos 4

Many of us (especially those involved in PBB creations, continue to)  check out the Libronix 3 ["about this resouce" - "learn more about this resource" etc]  in order to see what has or has not been tagged.

Thank you for the further  promised and anticipated work to be done in this area.

 

Regards, SteveF

Posts 13379
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, May 17 2010 3:04 PM

Louis,

Thank you for the helpful reply and for a glimpse into your plans. I'm glad you're looking to improve things looking forward. I still don't understand what you'd lose by having lexicons as listed in two languages, though I'm clear about what would be gained. Neither do I see what is lost when tagging translated ancient manuscripts as ancient manuscripts - regardless of the language. What would a 3rd century pseudepigraphal document that only exists in a 12th century Latin fragment be tagged as?

Can I also politely request that you consult users before making changes to your metadata policies. There are a number of us who are quite passionate about metadata on this forum (sad but true!), as I'm sure the size of the Wiki page and the number of related threads testifies. If you published your proposals before implementing them, I think you'd get some very helpful feedback that may prevent further upset in the future.

On a related note, could I plead that new titles have accurate metadata, please. I'm still waiting for two of my NIBC commentaries to have series tags.

Posts 489
LogosEmployee
Louis St. Hilaire | Forum Activity | Replied: Mon, May 17 2010 5:10 PM

Hi Mark,

In all of these cases, these are actually the standards that have been in force in our Text Development department for quite a while, so from our perspective, they don't represent changes. Unfortunately, they haven't always been followed consistently, so we've ended up confusing user expectations and have some work to do to bring old resources into line with current stanards.

What we lose in having a lexicon tagged with both languages is the distinction between what language a book is "in" and what language a book is "about". The intent of the field has always been to reflect the language the book is "in", and any of our text development processes or functions within the software that use the field are built on this assumption. As I said, I think the suggestion of using subjects (consistently) to address this is more correct and less disruptive.

By "translation", I meant "modern translation", and I've updated the wiki page to clarify this. Obviously, there are borderline cases for any such categorization, and we can't entirely escape some artibrary judgments. (Even if we clear up what qualifies as "ancient", I'd say there's still something fishy about calling an electronic version prepared from a modern printed edition, itself sometimes created using multiple witnesses, manu-scriptum, when it's at least twice removed from anything hand-written Smile.)

Following the forum, we're quite aware that users are passionate about every aspect of Logos. Since changes to metadata policies require library-wide fixes and changes in the software and our text development processes, they are rare--hence the reluctance to adopt these proposals, which, from our end, represent changes to current policy. Now that these fields are more transparently available to users, we have additional reasons for caution. To illustrate the rarity of such changes, I would say that, in my five+ years in Text Development here, spanning LDLS 2.1  to Logos 4, I can't recall another change to existing metadata that's anywhere near the scale of the change to the dictionary type that I spoke of. Changes are usually in the form of new fields or new possibilities within fields that enable new features for new resources but leave existing metadata untouched.

Nonetheless, metadata is subject to the same feedback system as other features within the software. We can't possibly promise democracy or consultation on every new feature, but the forum is always a place for users to tell us they love it, hate it, or want something else.

Again, my apologies on the backlog in metadata corrections. The problems that caused most of these errors in resources in the period following the launch of Logos 4 (such as NIBC) were resolved in mid-March, but we've been playing catch-up on fixing all the missing metadata published in that timespan. I've just gotten word that we'll be able to start working though what remains on the list, so you should be seeing some changes--at least to the most obvious things, like series-titles--soon.

Posts 25276
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, May 17 2010 5:29 PM

Louis Hilair,  I'm afraid you haven't made a good impression for metadata accuracy when you misquote my name!Huh?

Louis St. Hilaire:

We are actually planning to split the dictionary type into a few more types that will be more specific. Once we've sorted through the category and are ready to launch the changes, we'll make an announcement with complete details so that you can adjust your collections accordingly.

Using subjects for this purpose would be more appropriate. When we make the change to the dictionary types, we'll also make sure we have consistency in the subjects to make this easier.

Please submit this strategy to users for comment rather than present a fait accompli.  We are, and have been for many years, very passionate about library metadata.

Louis St. Hilaire:

Right. Our use of "Bible Notes" has been terribly inconsistent to the point that you can't really force it into a pattern. I ought to have been more clear that this is an attempt to provide a simpler definition that requires corrections on our end to implement rather than an explanation of things as they stand.

As for "who decides", my intent was to say that simple and broad categories leave us with fewer arbitrary judgments to make between types of books organized and indexed by Bible verse, which leads to more straighforward behavior within the software for such books and more flexibility for the user to categorize and prioritize what shows up in his Passage Guide. (Also, just to be clear, both "Bible Notes" and "Commentary" show up in the Passage Guide, so this particular distinction doesn't affect that function.)

As we understand how resources of both these types can now be user-selected for use in Passage Guide may I suggest that all "Study Bibles" titles be classed as type:Bible Notes provided that they are indexed by Bible ('The So that's Why! Bible' is an outright anomaly). This will populate Bible Notes whilst being slightly more objective about books that are classed as a Commentary.

Dave
===

Windows 10 & Android 8

Posts 18822
Rosie Perera | Forum Activity | Replied: Mon, May 17 2010 5:41 PM

Dave Hooton:

Louis Hilair,  I'm afraid you haven't made a good impression for metadata accuracy when you misquote my name!Huh?

Ha, ha! That's Hilairious! Big Smile

Posts 489
LogosEmployee
Louis St. Hilaire | Forum Activity | Replied: Mon, May 17 2010 6:04 PM

Dave Hooton:
Louis Hilair,  I'm afraid you haven't made a good impression for metadata accuracy when you misquote my name!Huh?

Oops. Sorry Embarrassed. Irony noted.

Dave Hooton:
As we understand how resources of both these types can now be user-selected for use in Passage Guide may I suggest that all "Study Bibles" titles be classed as type:Bible Notes provided that they are indexed by Bible ('The So that's Why! Bible' cannot be included in PG).

Yes, I concur.

Posts 27926
Forum MVP
MJ. Smith | Forum Activity | Replied: Mon, May 17 2010 6:14 PM

Dave Hooton:
Louis Hilair,  I'm afraid you haven't made a good impression for metadata accuracy when you misquote my name!Huh?

And misquoting Louis' name is your revenge? tsk... tsk... other cheek (or was it 'be cheeky')?Wink

Orthodox Bishop Hilarion Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."

Posts 25276
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, May 17 2010 7:09 PM

MJ. Smith:
And misquoting Louis' name is your revenge?

As long as nobody thought I was really upset ....

Dave
===

Windows 10 & Android 8

Posts 1367
JimTowler | Forum Activity | Replied: Mon, May 17 2010 8:10 PM

I support getting Metadata right.

Currently, the Metadata fields are "overloaded": (1) They are used internally by Logos processes and software to trigger how they work, and where they can appear. (2) The customers (thats us) are using the fields for Collections and searching. At present those needs don't match up too well.

Can I suggest it would be great if Logos4 allowed 10 new user-fields, in addition to the current "MyTags", which we currently "massively overload" in an attempt to work-around the current faults in the Metadata fields.

If we had new fields: User0, User1, User2, User3 ... User9 for all our resources; we could use some of these NOW to make our own corrections and use them in place of the default metadata fields that are problems.

Such user fields could be ignored by most users that have little or no interest in them, but could provide important work-arounds and new options for those where its a big deal. Some of us have well over 1,000 resources and the current issues limit the value of adding new ones. (I too had a nightmare with 2 of my NIBC volumns missing from some of my collections and reports.)

Adding User0...User9 should NOT stop the work on getting the Metadata issues addressed, and working with users on a plan, but seems to me as something that could be added with little delay, and need break nothing in the processing, tagging and release of new resources.

Comments?

Posts 27926
Forum MVP
MJ. Smith | Forum Activity | Replied: Mon, May 17 2010 8:58 PM

Jim Towler:
Comments?

You can enter multiple, independent mytags already. Do we really need additional fields? I.E. what advantages do you see in your suggestion over the current situation?

Orthodox Bishop Hilarion Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."

Posts 349
Frank Fenby | Forum Activity | Replied: Mon, May 17 2010 9:07 PM

Jim,

Might I suggest the opposite. Have Logos fields 0-9 or what ever, that they need for program control. Then let the meta-data be true meta-data describing the resource in standard library science terminology. The visible meta-data should not be used for program control. This way if the visible meta-data needs to be changed for any reason it can change without having to coordinate with a program update.

The problem with just a string of user fields is that everyone will have to duplicate what should be standard. It means each Logos user will need to earn an MLS degree. Wink And it will be hard to communicate with each other because we will all have defined our series, language, type, etc. in different ways.

It could easily become a nightmare if, when we teach an ordinary mortal person to use Logos, we have to teach them library science first so they can set up the meta-data, so they can set up their collections, so they can run a simple report so they can learn about Jesus.

Posts 27926
Forum MVP
MJ. Smith | Forum Activity | Replied: Mon, May 17 2010 10:19 PM

Frank Fenby:
This way if the visible meta-data needs to be changed for any reason it can change without having to coordinate with a program update.

I don't quite understand why you think this follows. Could you elaborate please.

Orthodox Bishop Hilarion Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."

Posts 1367
JimTowler | Forum Activity | Replied: Mon, May 17 2010 11:02 PM

MJ. Smith:
You can enter multiple, independent mytags already. Do we really need additional fields? I.E. what advantages do you see in your suggestion over the current situation?

MJ,

Thats easy!!!

Firstly, Logos only needs to add support for the named fields: User0 ... User9 to the list of possible fields, and update the database structures that hold and manage the fields, then leave us to use as we like. It should be easy, cheap and simple to add. Also document as user fields. How I use them is up to me. If I don't need them, thats fine. If I want to treat User0 as a replacement for language, I can do so if I wish. If I want to use User7 as an alternative author field in some collections, thats up to me. Let me do as I want with them.

Using the current MyTags field, its not really practical to use it for multiple purposes.

Imagine me doing something like:

User0: Greek
User1:
User2:
User3:2010_05_02
User4:March Madness 2010
User9:HIDE

So, I'm using User3 for the date I purchased it, User4 for the package or special, User9 as a HIDE so I can exclude it from most things, except for still finding it on an All Library search and so ...

With MyTags, I have to use MyTag="L_Greek, P2010_05_02, Deal_March_Madness_2010, HIDE"
so I can build Collection rules or something. YUCK!!!

I still need/want Logos to fix the Metadata errors, but I want more user fields. Best would be let me make an unlimited number of them, and give them meaningful names, but thats a lot more work than giving me User0 ... User9 and let me do as I like. At least for now ...

Posts 1367
JimTowler | Forum Activity | Replied: Mon, May 17 2010 11:11 PM

Frank Fenby:
It could easily become a nightmare if, when we teach an ordinary mortal person to use Logos, we have to teach them library science first so they can set up the meta-data, so they can set up their collections, so they can run a simple report so they can learn about Jesus.

Frank,

NO  - it need not be that hard.

Firstly, "normal users" don't need to touch these fields if they don't want. And they would be clearly documented as user fields. Logos needs to have little more to do with them except to support them in library searches, Collection creations etc. (And of course entend the edit portions that let us change the current MyTags field to include User0...User9).

"Power Users" can do as they like with them if they wish.

And, this is NOT to replace the need for Logos and users to work on improved Metadata. What I am suggesting is a simple and fast way to give us an urgent work-around, and a long-term way of managing our growing resource libraries.

Just as I might put all my new paper books on one shelf near the bed, and older ones by topic in the main bookcase, and ones I dislike in the basement ... these fields would let me do as I like. The current MyTags is great, but I'm already using the field for multiple purposes and its not pretty!

Posts 13379
Forum MVP
Mark Barnes | Forum Activity | Replied: Tue, May 18 2010 1:00 AM

Jim Towler:
If we had new fields: User0, User1, User2, User3 ... User9 for all our resources; we could use some of these NOW to make our own corrections and use them in place of the default metadata fields that are problems.

No, I don't agree with this. The metadata's main value is in creating dynamic collections. Collections are not dynamic if I have to create the data for them! Logos need to get it right - we have tags which are entirely flexible.

Posts 18822
Rosie Perera | Forum Activity | Replied: Tue, May 18 2010 1:31 AM

Mark Barnes:

Jim Towler:
If we had new fields: User0, User1, User2, User3 ... User9 for all our resources; we could use some of these NOW to make our own corrections and use them in place of the default metadata fields that are problems.

No, I don't agree with this. The metadata's main value is in creating dynamic collections. Collections are not dynamic if I have to create the data for them! Logos need to get it right - we have tags which are entirely flexible.

If Logos is overloading the metadata for two purposes (how the resources behave in the program vs. how users can filter their library and make collections out of them), maybe they just need to create one new internal-only metadata field for resource_type which would determine how the resource behaves in the program. There might be other internal ones they'd need that I'm not aware of, but this is the one that seems to be causing the most trouble to users.

Page 1 of 3 (42 items) 1 2 3 Next > | RSS