LOGOS: Your recent response to Metadata Tagging Proposals

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.

https://community.logos.com/discussion/comment/129543#Comment_129543

As a further follow up, Logos said this:

“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.

Louis St. Hilaire

https://community.logos.com/discussion/comment/129556#Comment_129556

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.

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.

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.)

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.

SteveF

https://community.logos.com/discussion/comment/129662#Comment_129662

Dear Louis St. HIlaire:

Thanks so much for your response to Dave and Mark.

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

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.

https://community.logos.com/discussion/comment/129679#Comment_129679

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.

Louis St. Hilaire

https://community.logos.com/discussion/comment/129769#Comment_129769

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 [:)].)

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.

https://community.logos.com/discussion/comment/129662#Comment_129662

Louis Hilair, I'm afraid you haven't made a good impression for metadata accuracy when you misquote my name![:^)]

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.

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.

Rosie Perera

https://community.logos.com/discussion/comment/129820#Comment_129820

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

Ha, ha! That's Hilairious! [:D]

Louis St. Hilaire

https://community.logos.com/discussion/comment/129820#Comment_129820

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

Oops. Sorry [:$]. Irony noted.

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.

https://community.logos.com/discussion/comment/129820#Comment_129820

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

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

https://community.logos.com/discussion/comment/129837#Comment_129837

And misquoting Louis' name is your revenge?

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

https://community.logos.com/discussion/comment/129851#Comment_129851

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?

https://community.logos.com/discussion/comment/129865#Comment_129865

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?

https://community.logos.com/discussion/comment/129865#Comment_129865

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. [;)] 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.

https://community.logos.com/discussion/comment/129873#Comment_129873

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.

https://community.logos.com/discussion/comment/129872#Comment_129872

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 ...

https://community.logos.com/discussion/comment/129873#Comment_129873

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!

https://community.logos.com/discussion/comment/129865#Comment_129865

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.

Rosie Perera

https://community.logos.com/discussion/comment/129897#Comment_129897

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.

https://community.logos.com/discussion/comment/129812#Comment_129812

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.

Louis, first let me thank you for the opportunity to consider your approach and strategy, and to discuss alternatives. I hadn't been overly concerned about the Languages field but a number of fine distinctions have crept in with a few types:-

Greek/Hebrew Bibles - are they "in" Greek/Hebrew or intended for the English reader? Clearly, English bibles are both.
Dictionaries - all "in" English, some "in" multiple languages
Clause Visualizers - one "in" Greek, one "in" Hebrew, two "in" no language. All with no Subjects field.
Ancient Manuscript - the one I have is "in" Greek with no Subjects field.

So there will be some disruption with change!

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.

I am somewhat disappointed with that statement because policy should never be rigid and it would have been expected that the anomalies that existed during L3 would set the scene for policy changes with the development of L4 and dynamic collections. Instead we are discussing policy 6 months after its release and still inherit the legacy of L3. Please don't think I'm scoring points but it was stated earlier in the year (or late last year) that we would see changes "soon".

https://community.logos.com/discussion/comment/129897#Comment_129897

No, I don't agree with this.

My mistake for mixing two ideas: You want metadata fixed. I want some user fields so I can better manage my 1000+ resources which I have paid to have access to. Silly me to think it might also give you an instant work-around for your problem too.

I will leave for others to battle their metadata concerns.

And no, we don't have tags. We only have one tag. Already overloaded by users given the different kinds of things people are using the one field for.

https://community.logos.com/discussion/comment/129905#Comment_129905

And no, we don't have tags. We only have one tag.

We do have tags. We have multiple tags in one field. There's no reason why you can't use that field for multiple purposes. I'm not sure exactly what your purposes are, but from your earlier example, you could tag a book like this:

lang-Greek, boughtdate-2010_05_02, deal-march-madness-2010, bundle-scholars, visibility-hide

I appreciate that's slightly more typing, but it should give you what you need - all from the one field. Is it ugly? Perhaps, but it's functional - it works. And it works without any changes to Logos architecture.

James W Bennett

https://community.logos.com/discussion/comment/129906#Comment_129906

And no, we don't have tags. We only have one tag.

We do have tags. We have multiple tags in one field. There's no reason why you can't use that field for multiple purposes. I'm not sure exactly what your purposes are, but from your earlier example, you could tag a book like this:

lang-Greek, boughtdate-2010_05_02, deal-march-madness-2010, bundle-scholars, visibility-hide

I appreciate that's slightly more typing, but it should give you what you need - all from the one field. Is it ugly? Perhaps, but it's functional - it works. And it works without any changes to Logos architecture.

But then he has to build a keyword for every possibility and can't have multiple values in a single field as easily. It make for a lot more typing, especially setting up the collections themselves. Also he can't do something like boughtdate < '2010/05/02'.

James W Bennett

https://community.logos.com/discussion/comment/129930#Comment_129930

As an outsider looking in, I do not know how Logos was coded so
this may not work, but it is worth asking about. Could we use the following scenario. It would allow User's the flexibility they need and the individuality they need in their own quirks for cataloging and allow Logos not to change internally too much.

Leave the metadata the way it is and Logos can continue using it. Have a secondary repository of tags that by default for each keyword contain the metadata information, maybe calling the repository cataloquedata or some such. Same name and content for each keyword such as "title" or "type". Collections and probably searching would use the keywords from the new repository. Everything else in Logos look at the metadata repository.

If this could be done then an interface could be made so the users can change the catalogue data for any given resource. If I want to build a collection about Aramaic lexicons I can either use the methods Logos has mentioned by checking subject (which I abhor because they are so non-uniform at this time) or I can add Aramaic as a language to a lexicon. While new resources won't have the new data and set so won't be added to the collection if I set my rules up the way Logos intends the dynamicness still works. I can choose to break dynamicness or use it depending upon my needs.

It will also get around the limitations I outlined above since we still have individual fields. It is sort of like the UserX tags proposed but does not require every field to be setup manually because it gets a default. You could even allow users to add their own keywords that they can then use in Collections and keyword searching. Although I would suggest users be allowed to name them if they do not conflict with already existing names. You don't want users having to remember to search for all user9 that are brown when they want to search for all widgets that are brown.

https://community.logos.com/discussion/comment/129931#Comment_129931

It may be better to take the "additional fields" discussion over to this post which Jim created part-way through this thread. As Jim pointed out, it may get a bit confusing if we're talking about structural catalogue changes and customisable meta-data in a thread about consistent and accurate metadata from Logos.

https://community.logos.com/discussion/comment/129880#Comment_129880

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.

I remember a comment or two from Logos that meta-data changes "can" require program updates. IMHO meta-data should be no more complicated to change then correcting a spelling error in a resource. In "a former life" as a computer business system designer, I would not allow a field to have multiple meanings. Every time I did allow it, I got in trouble, so I outlawed it. Meta-data for collection building is a different "meaning" (construct) than meta-data for program control. They should, IMHO, be independent variables (separate fields).

https://community.logos.com/discussion/comment/129936#Comment_129936

In "a former life" as a computer business system designer, I would not allow a field to have multiple meanings.

Frank,

YES - That was my point about users overloading what they store in "MyTags" and the conflict with Logos using the metadata tags for internal use, and users attempting to build collections and rules from them. Overloading their meaning just as you also wrote about above.

As Mark comments, its best to keep this thread about Logos improving Metadata standards and updating resources.

(And the other thread about ways of adding custom tags for whatever users what. I think its best if they could be unlimited and named as we like, but the User0...user9 idea was to let us have something quick, simple and soon.)

https://community.logos.com/discussion/comment/129936#Comment_129936

Logos has the ability to push metadata updates without even a resource update, never mind a program update. But it couldn't change the "type" of a resource without re-compiling the resource. And introducing new "types" would obviously require a program update to handle them.

I agree about the theoretical need not to mix constructs. There was a discussion some weeks ago on whether fragments of the OT pseudepigrapha should be classifed as "bible". Internally they need to. For many end-users that's a problem - but we learn to live with it because we understand why it's necessary. (But let's take "ancient manuscript" as an example. An ancient manuscript does not become a monograph just because it has been translated, whether for internal programming use or end-user use. That's an editorial decision, not a programming one.)

https://community.logos.com/discussion/comment/129885#Comment_129885

The current MyTags is great, but I'm already using the field for multiple purposes and its not pretty!

Adding more user fields may be a good idea. I just want the meta-data that is shipped with the product to be changeable by Logos (alone) without having to coordinate it with a program release.

https://community.logos.com/discussion/comment/129941#Comment_129941

For many end-users that's a problem - but we learn to live with it because we understand why it's necessary

"In the best of all possible worlds," to quote the philosopher in Voltaire's Candide, we should not have to live with it. It would, however, take separating "collection building" meta-data from "program control" meta-data (two different constructs).

https://community.logos.com/discussion/comment/129942#Comment_129942

The current MyTags is great, but I'm already using the field for multiple purposes and its not pretty!

Adding more user fields may be a good idea. I just want the meta-data that is shipped with the product to be changeable by Logos (alone) without having to coordinate it with a program release.

Unfortunately, the metadata changes discussed by Louis and myself will result in changes to both L4 and the definition of user dynamic collections. Thereafter your ideal should be achievable (and also not impact users!).

https://community.logos.com/discussion/comment/129946#Comment_129946

I've just discovered that categorising translated ancient manuscripts as monographs prevents parallel resources working properly. Another reason why it's the wrong policy in my view.

https://community.logos.com/discussion/comment/129936#Comment_129936

In "a former life" as a computer business system designer, I would not allow a field to have multiple meanings. Every time I did allow it, I got in trouble, so I outlawed it. Meta-data for collection building is a different "meaning" (construct) than meta-data for program control. They should, IMHO, be independent variables (separate fields).

Thanks for the explanation. I view it slightly differently in that most of my collections are based on the same definitions as Logos' metadata. I use mytags when I want to use independent variables. I assumed that the need to make program updates was solely because of legacy data and would cease to occur once all metadata was converted to the current standards. I agree that accurate data modeling, including normalizing, is essential to a successful system.

https://community.logos.com/discussion/comment/129936#Comment_129936

I remember a comment or two from Logos that meta-data changes "can" require program updates. IMHO meta-data should be no more complicated to change then correcting a spelling error in a resource. In "a former life" as a computer business system designer, I would not allow a field to have multiple meanings. Every time I did allow it, I got in trouble, so I outlawed it. Meta-data for collection building is a different "meaning" (construct) than meta-data for program control. They should, IMHO, be independent variables (separate fields).

I agree with this. It's a standard procedure of normalization to identify any multiple values in single fields and split them into individual fields. This allows for far more powerful indexing, and if this change was made to Logos then collection rules could be even more flexible and intuitive.

Rosie Perera

https://community.logos.com/discussion/comment/183101#Comment_183101

I agree with this. It's a standard procedure of normalization to identify any multiple values in single fields and split them into individual fields. This allows for far more powerful indexing, and if this change was made to Logos then collection rules could be even more flexible and intuitive.

I would also love to be able to have multiple user-defined fields, not have to overload tags the way we do now. I use it to record what base package or bundle I purchased a resource in, what date I bought it, whether it was a pre-pub or a special sale, and then all the tags I want to use for making collections. It would be nice to be able to view my library sorted in chronological order by when I acquired each resource. That way I can continue focusing on familiarizing myself more with the more recently purchased books. Can't do that now the way tags currently work. Well, I can group by tag, and that is sort of what I want, but then I've got to expand each date to see what items I bought on that date. And there's all the other clutter and redundancy since there's a group for each tag I've used.

https://community.logos.com/discussion/comment/183189#Comment_183189

I would also love to be able to have multiple user-defined fields, not have to overload tags the way we do now. I use it to record what base package or bundle I purchased a resource in, what date I bought it, whether it was a pre-pub or a special sale, and then all the tags I want to use for making collections. It would be nice to be able to view my library sorted in chronological order by when I acquired each resource. That way I can continue focusing on familiarizing myself more with the more recently purchased books. Can't do that now the way tags currently work. Well, I can group by tag, and that is sort of what I want, but then I've got to expand each date to see what items I bought on that date. And there's all the other clutter and redundancy since there's a group for each tag I've used.

Rosie, I'm replying to this partly to bump the thread in order to revive interest in it. I would actually like to know who is interested in this suggestion. I don't expect it will appear necessary to the majority of users, but I would like to exchange ideas with those whom it does interest.

David P. Moore

https://community.logos.com/discussion/comment/187894#Comment_187894

Jonathan, I'm hanging around, too. I think it would be great to work with Logos to address these issues.

https://community.logos.com/discussion/comment/187921#Comment_187921

David, you have email.

https://community.logos.com/discussion/comment/187894#Comment_187894

It would be nice to be able to view my library sorted in chronological order by when I acquired each resource. That way I can continue focusing on familiarizing myself more with the more recently purchased books.

EDIT: the quote is Rosie's!

The 4.2 Beta has introduced a field called Last Updated which will allow you to do that (but you have to distinguish a newly purchased resource from an updated one).

I have been able to remove three of my tags with the recent rationalisation of resource language in Subjects + introduction of type:lexicon and type:encyclopedia to distinguish the former type:dictionary resources. Otherwise, I was heading down the route of tag overload for the purpose of defining collections. I would support one additional user-defined field, though.

https://community.logos.com/discussion/comment/188087#Comment_188087

That's actually Rosie's post Dave, but thanks for the tip about the new field. I'm going to revisit my dictionaries and encyclopedias collection to see how I can improve the rule on the basis of the new tag types.