LOGOS: Your recent response to Metadata Tagging Proposals
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 language of a book is the primary language it is written in
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.
- Logos’ use of these types is primarily functional rather than
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 11 & Android 13
Comments
-
Dave Hooton said:
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
As a further follow up, Logos said this:
Logos said:“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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
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 said: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 said: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 said: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.
0 -
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 said: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
0 -
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
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.
0 -
Louis Hilair, I'm afraid you haven't made a good impression for metadata accuracy when you misquote my name![:^)]
Louis St. Hilaire said: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 said: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 11 & Android 13
0 -
Dave Hooton said:
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]
0 -
Dave Hooton said:
Louis Hilair, I'm afraid you haven't made a good impression for metadata accuracy when you misquote my name!
Oops. Sorry [:$]. Irony noted.
Dave Hooton said: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.
0 -
Dave Hooton said:
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')?[;)]
Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
0 -
MJ. Smith said:
And misquoting Louis' name is your revenge?
As long as nobody thought I was really upset ....
Dave
===Windows 11 & Android 13
0 -
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?
0 -
Jim Towler said:
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 Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
0 -
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.
0 -
Frank Fenby said:
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 Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
0 -
MJ. Smith said:
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:HIDESo, 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 ...
0 -
Frank Fenby said:
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!
0 -
Jim Towler said:
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:Jim Towler said:
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.
0 -
Louis St. Hilaire said:
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!
Louis St. Hilaire said: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".
Dave
===Windows 11 & Android 13
0 -
Mark Barnes said:
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.
0 -
Jim Towler said:
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:Jim Towler said:
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'.
0 -
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.
0 -
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
MJ. Smith said:Frank Fenby said:
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).
0 -
Frank Fenby said:
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.)
0 -
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.)
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Jim Towler said:
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.
0 -
Mark Barnes said:
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).
0
