Re: entry/subentry, root-based/stem-based, major/minor entry, and publication implications

[J V C]

Correction: The paragraph,"The FLEx UI..." should have read as follows (corrections underlined). Thanks for catching those, Kevin!

It also results in a more specific automatic minor entry ("bathtub: see tub sense 1"). In stem-based mode, "tub" and "bathtub" would both be main entries that simply link to each other ("tub n. ... see bathtub" and "bathtub n. ... see tub sense 1").

Jon

On 3/12/2014 4:54 PM, Jonathan & Veronica Coombs wrote:

There seems to be a lot of confusion surrounding these topics--they are indeed tricky--and I just wrote something up in response to an individual. Then I thought that it might be relevant to this group as well. So, here's a somewhat expanded version for those who may be interested. (I've relied on bold and italics quite a bit, so I hope those come through.)

Jon

Under Tools, Configure Dictionary, FLEx has stem-based and root-based modes. That dialog lists Main Entry and Minor Entry, and when in root-based mode it also lists Subentry. What are these, and how do they relate to "variants" and "complex forms" and "minor subentries"? For starters, a main entry is a published entry/subentry that shows a headword and all detailed information; a minor entry is basically just a published link to a main entry, though it may include a category or summary definition.

It would be helpful for you to decide up front what the desired output should look like. That can help you choose the correct or best structures. I'll describe some examples and concepts below. Oh, and these Help pages have a good introduction to this, with examples, so you might read them first: "Root-based view", "Referenced Complex Forms (Config. Dict.)"

For a visual big picture, I'll show the examples first. (The definitions are totally of the cuff.)

=== STEM-BASED ===
bathtub  (tub) n  a tub for bathing in.
...
tub  n  1) a container, typically broader than it is
high.   2) a bulky and/or slow boat. Complex
forms: bathtub 

=== ROOT-BASED ===
bathtub  n  See under: tub
...
tub  n  1) a container, typically broader than it is
high.   2) a bulky and/or slow boat. 
  bathtub  n  a tub for bathing in.

=== STEM-BASED (specific sense) ===
bathtub  (tub 1) n  a tub for bathing in.
...
tub  n  1) a container, typically broader than it is
high. Complex forms: bathtub   2) a bulky and/or
slow boat.

=== ROOT-BASED (specific sense) ===
bathtub  n  See under: tub 1
...
tub  n 
    1) a container, typically broader than it is
        high.
    bathtub  n  a tub for bathing in. 
    2) a bulky and/or slow boat.

"Complex forms" are words/phrases that can be published as either entries or subentries, depending on the publishing mode. One thing to keep in mind is that what something *is* is determines how it can be *published*, but these are distinct concepts. It's great that FLEx keeps these concepts separate, but it can be confusing at first. The publishing terms "entry" and "subentry" both refer to a complete entry with all the information (definition, examples, etc.), but a subentry is located under its root (or a specific sense of its root) instead of being located alphabetically. There are no subentries in stem-based mode.

Both "entry" and "subentry" are stored as "entry" in FLEx. The only difference is that, if you switch to root-based publishing mode, a FLEx entry that is complex ("bathtub") will be published as a subentry under one or more component entries (that is, under "tub" and/or "bath"), and an automatic minor entry may display ("bathtub : see tub"). To FLEx, an entry is complex iff its Components link field isn't empty.

So, users of the default stem-based view rarely talk about "complex forms". For stem-based, one Component<->ComplexForm link doesn't affect much; it is almost identical to one simple CrossReference<->CrossReference link, except that the two ends of the link are labeled differently (and might include extra info).

The FLEx UI provides the option of linking to a specific sense of a component. In root-based mode, this forces each sense to start a new paragragh, and it double indents the subentry under its specific sense. It also results in a more specific automatic minor entry ("bathtub : see tub sense 2"). In stem-based mode, tub and bathtub would both be main entries that simply link to each other ("tub n. ... see bathtub" and "tub n. ... see tub sense 2").

So, even though you can easily switch back and forth, it's a big decision to choose between stem-based and root-based mode. Linking Components/Complex Forms is very necessary for root-based mode, but it isn't very important in stem-based mode. Also, the only kind of minor entry in stem-based mode is for variants, and you can actually create these directly as entries in FLEx (with Variant Of filled in, and usually with no Senses at all).

In root-based mode, in addition to variants, there is a second kind of minor entry that points to a subentry's root, but you cannot directly create a minor entry for a complex form. Instead, you create an complex entry, which will publish as a subentry. A minor entry is then generated automatically, if you leave the "Show Minor Entry" box ticked.

Minor subentries: In the two stem-based examples above, "Complex forms: bathtub" is a miniature subentry linking to a main entry--that is, it is basically a minor subentry. However, the FLEx glossary actually defines the term as specific to root-based mode, in this scenario: an entry for bath has been added and linked to as a component, but the user hasn't chosen to publish a complete copy of the bathtub subentry under the root bath. So, a minor subentry is shown under bath instead. (If the subentry had lots of senses with lengthy definitions and examples, this could save paper. But it's nicer to the reader to include the full thing.)

=== ROOT-BASED (with a minor subentry shown) ===
bath  n  the event of washing oneself. Complex
forms: bathtub (see under tub) 
bathtub  n  (tub, bath); see under: tub
...
tub  n  1) a container, typically broader than it is
high.   2) a bulky and/or slow boat. 
  bathtub  n  a tub for bathing in.

NOTE to those with SFM data: This confusion can also exist in the Toolbox world (though it's more common in FLEx because all its sorts and editing modes are stem-based). One time when I was importing an MDF dictionary, I noticed a lot of \ln fields, but only in \lf \lv links that pointed to complex forms. I asked, and it turned out that "\lf x \lv y \ln z" simply needed to be changed into "\se y \gn z". After import, those subentries looked just like he wanted--in root-based mode.

THE END

[Andrea Patten]

Hello,

I am slogging my way by trial & error through the Dictionary formatting for a root-based view. I've gotten as far as having two different subentries, one for "no complex type" and one for what I just labeled "contraction" (in order to differentiate), Subentry (1) being indented further under the already indented Subentry (major accomplishment = hrs of head banging). But now for a crowning achievement, I'm trying to also get the Subentry headword to be published as its own headword entry. Under Dictionary Views in the Help it says this is possible but does NOT explain HOW!

"Complex forms may be presented both as a headword and indented under their main (parent) entries, such as the derived form manly (below)."

I tried giving the root under "Show subentry under" AND give the complex forms under Subentries (& Referenced Complex), thinking this moderately complex word would both be listed under its root AND have its own main entry headword listing (with further complex forms underneath it).

(This is a constructed language based on semantic primes, so there are several degrees of complexity = words built up on roots).

I would so greatly appreciate some direction!

Andrea Weilgart Patten

(ps there are several glitches I've discovered, e.g. if a word was originally listed as a variant of, it will not show up if it is made a subentry, unless both the 'variant of' word is deleted AND the entry needs to be totally re-entered, the original entry deleted). Also I can not get a manual re-ordering of the complex forms be reflected in the Dictionary view.