Lojban word definitions style guidelines

[Ilmen]

coi ro do

A couple of weeks ago, Naours (aka Xelan) suggested to make an official set of style guidelines for Lojban word definitions, in order to have definitions that look better and have a consistent style across the dictionary.

Those guidelines would also aim at reducing the use of slashes '/' in definitions, favoring the use of the gloss fields for listing natural language equivalent words or expressions. The rational for this is that slashes make definitions more clunky and less pretty, and the result can be awkward in languages with inflectional agreements.

Below is Naours' proposal, translated from French and slightly modified/adjusted by me (hopefully without misrepresenting the idea of its author).

mu'o mi'e la .ilmen.

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Propositions:

* Most important points:
→ Each definition must have a clear description. Slashes '/' should be avoided as much as possible, as they hinder comprehension and make definitions look awkward.
→ Each definition must have a simple description: the description is written using simple terms, even if that leads to more verbosity.
→ Each definition must have a description as generic as possible: only one term per concept, as generic as possible for encompassing the other appropriate terms.
→ Every terms corresponding to the described concept are recorded in the gloss fields.
→ The etymologies are presented along with the definition in order to retain the term and its origin.
→ The various sumti types must be specified between parentheses:
    — Proposition (bridi abstractor - lo du'u)
    — Event (action or state; event abstractor - lo nu)
    — Property/dimension (property abstractor - lo ka)
    — Quantity (quantity abstractor - lo ni)

* Points that may need to be further discussed:
→ The sumti are described using singular definite articles.

Expected results example:

balni (gimsu)
Description: x1 is a platform overhanging on facade x2
Gloss: {balcony, overhang, ledge, shelf}
Exemple 1:
  (English): This is a balcony
  (Lojban): ti balni
Exemple 2:
  (English): The balcony of this building
  (Lojban): lo balni be lo vi dinju
Etymology:
  Chinese: iantai
  English: balkani
  Hindi: baramda
  Spanish: balkon
  Russian: balkon
  Arabic: curfa
Notes:

Some points are rather advanced, and it will maybe be necessary to modify/improve/remove them.

mu'o mi'e la .na'urs.

[Ilmen]

I don't know how much dictionary definition guidelines are relevant to the BPFK, but for lack of a better alternative, I've sent Naours' proposal here, to the BPFK list.

Indeed, even if the BPFK were to publish official definition guidelines or recommendations, this wouldn't magically change all the existing definitions ; however this may be a good idea in order that future/newer definitions have a nicer and more consistent style.

Also, it would be nice to have official recommendations on how to represent sumti slots in Lujvo definitions. As of now, the x+N system, the gismu_first_letter+N system and a mix of both systems are currently in use, which make lujvo definitions' style inconsistent across the dictionary.

As a side note, it's not yet possible to attach a natural language translation to Lojban sentence examples in Jbovlaste, so there may also be technical hindrances to such a proposal. However it's still possible to put translated examples directly into the notes field, although it's conceptually less nice.

mi'e la .ilmen. mu'o

[Alex Burka]

Makes sense to me. Thanks for translating/sending. The BPFK does write cmavo definitions, so the guidelines may be relevant. I am a huge fan of eliminating slashes from definitions wherever possible -- the slashes create ambiguities when reading. It's like a universal connective system, except in English, unlike Lojban, you can't tell unambiguously what the connective is supposed to be connecting.

As for sumti slots in lujvo definitions, I favor the hybrid system (x1=g1=s2 is a thing with ...). It's visually noisy, but it manages to (1) number the places without obliging the reader to count and (2) show the "etymology" of each place, where that is relevant. I consider (1) more important -- perhaps the notes are a better place to say which terjvo came from which veljvo. I don't like using only the gismu_first_letter+N system because then the N doesn't correspond to the FA you need to use and you have to count while reading the definition.

I agree that example sentences should be linked to their natlang equivalents. I never understood why JVS doesn't do that. I know that part of the point of an example is just to show the word in context, but the translation is often necessary too. A workaround is to put something like {lu ... li'u xe fanva zoi gy. ... .gy} as the example.

- mu'o mi'e durkavore

--
You received this message because you are subscribed to the Google Groups "BPFK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bpfk-list+...@googlegroups.com.
To post to this group, send email to bpfk...@googlegroups.com.
Visit this group at http://groups.google.com/group/bpfk-list.
For more options, visit https://groups.google.com/d/optout.

[selpa'i]

la durka cu cusku di'e

> As for sumti slots in lujvo definitions, I favor the hybrid system
> (x1=g1=s2 is a thing with ...). It's visually noisy, but it manages to
> (1) number the places without obliging the reader to count and (2) show
> the "etymology" of each place, where that is relevant. I consider (1)
> more important -- perhaps the notes are a better place to say which
> terjvo came from which veljvo.

I would think so. I prefer the simplest method: just x_n. Not everyone
cares about the origin of the lujvo places, and all those letters
clutter up the definition and make it look more like math than anything.

What I thought could work is to have an extra field apart from the
general notes field that can be used to give information about place
structure patterns ("families") and other place structure background.
Maybe a good dictionary frontend would allow the user to choose if they
want this field to be visible (like a show/hide button). Much like
etymology, it's not necessary to know about it, but it can be of value
to the interested.

I do think the definitions should be as easy to read as possible, and
readable by a layperson.

I talked to some people a while ago, and they told me the definition
style scared them off, because it reminded them of math. It wouldn't
hurt Lojban to cater to a wider audience (as crazy as that may sound!)
by making sure that any person with any background can access it. When
giving lessons to non-math/non-programming people I sometimes use
unnumbered blanks written by underscores, because the concept of filling
in the blanks is easy to grasp and less intimidating than "filling
argument places" for certain people. It looks like this:

dunda: ___ gives ___ to ___

I'm not saying this should replace the x1,x2,x3 style, but I think it is
a good alternative that could be implemented in some potential
dictionary interface as an additional option. Everyone should be able to
feel comfortable reading the dictionary.

mi'e la selpa'i mu'o

[Alex Burka]

On May 27, 2015 at 5:49:52 PM, selpa'i (sel...@gmx.de) wrote:

la durka cu cusku di'e 
> As for sumti slots in lujvo definitions, I favor the hybrid system 
> (x1=g1=s2 is a thing with ...). It's visually noisy, but it manages to 
> (1) number the places without obliging the reader to count and (2) show 
> the "etymology" of each place, where that is relevant. I consider (1) 
> more important -- perhaps the notes are a better place to say which 
> terjvo came from which veljvo. 

I would think so. I prefer the simplest method: just x_n. Not everyone 
cares about the origin of the lujvo places, and all those letters 
clutter up the definition and make it look more like math than anything. 

Fair enough. Sometimes it's easier to grok a lujvo definition when you can think, "oh, okay, this place is like bangu2 so it's an agent" but arguably this should be clear from the definition without looking into the etymology. And with naljvajvo it doesn't make sense. I do think that lujvo in jvajvo style, or close to it, should list their derivations somewhere.

What I thought could work is to have an extra field apart from the 
general notes field that can be used to give information about place 
structure patterns ("families") and other place structure background. 
Maybe a good dictionary frontend would allow the user to choose if they 
want this field to be visible (like a show/hide button). Much like 
etymology, it's not necessary to know about it, but it can be of value 
to the interested. 

+1

I do think the definitions should be as easy to read as possible, and 
readable by a layperson. 

I talked to some people a while ago, and they told me the definition 
style scared them off, because it reminded them of math. It wouldn't 
hurt Lojban to cater to a wider audience (as crazy as that may sound!) 
by making sure that any person with any background can access it. When 
giving lessons to non-math/non-programming people I sometimes use 
unnumbered blanks written by underscores, because the concept of filling 
in the blanks is easy to grasp and less intimidating than "filling 
argument places" for certain people. It looks like this: 

dunda: ___ gives ___ to ___ 

I'm not saying this should replace the x1,x2,x3 style, but I think it is 
a good alternative that could be implemented in some potential 
dictionary interface as an additional option. Everyone should be able to 
feel comfortable reading the dictionary. 

Definitely a good dictionary viewer could have an option to hide the xN and show blanks instead.

mi'e la selpa'i mu'o 

[Gleki Arxokuna]

Some of those guidelines would be better implemented by extending JVS db model. Also if we put variable types in brackets then nothing else should be in brackets.

Similarly, examples aren't supported by JVS 1.0 in a nice way.

Also while creating my dictionary I used "glosswords" to reflect English nouns. Using a separate field to gloss gismu as verbs would also be nice.

Also etymology somewhat contradicts my proposal: https://github.com/lojban/jbovlaste/issues/131 where we have etymology only in Lojban whereas for the other languages they can be generated by third party software like those that produce printable dictionaries.

[Alex Burka]

On May 28, 2015 at 2:07:38 AM, Gleki Arxokuna (gleki.is...@gmail.com) wrote:

Some of those guidelines would be better implemented by extending JVS db model. Also if we put variable types in brackets then nothing else should be in brackets.

Similarly, examples aren't supported by JVS 1.0 in a nice way.

Also while creating my dictionary I used "glosswords" to reflect English nouns. Using a separate field to gloss gismu as verbs would also be nice.

not a necessary distinction in Lojban

Also etymology somewhat contradicts my proposal: https://github.com/lojban/jbovlaste/issues/131 where we have etymology only in Lojban whereas for the other languages they can be generated by third party software like those that produce printable dictionaries.

Uh, what are they generating from, then?

[Gleki Arxokuna]

2015-05-28 17:47 GMT+03:00 Alex Burka <dur...@gmail.com>:

On May 28, 2015 at 2:07:38 AM, Gleki Arxokuna (gleki.is...@gmail.com) wrote:

Some of those guidelines would be better implemented by extending JVS db model. Also if we put variable types in brackets then nothing else should be in brackets.

Similarly, examples aren't supported by JVS 1.0 in a nice way.

Also while creating my dictionary I used "glosswords" to reflect English nouns. Using a separate field to gloss gismu as verbs would also be nice.

not a necessary distinction in Lojban

In Lojban no. For searching in the English-Lojban dictionary it's however useful. Otherwise people don't understand that {mlatu} is not "cat" but "x1 is a cat" and forget {lo}.

Also etymology somewhat contradicts my proposal: https://github.com/lojban/jbovlaste/issues/131 where we have etymology only in Lojban whereas for the other languages they can be generated by third party software like those that produce printable dictionaries.

Uh, what are they generating from, then?

As I understood in this proposal for every language there is a separate entry with etymology. All such entries can be autogenerated from Lojban one. 

[Ilmen]

On 28/05/2015 16:56, Gleki Arxokuna wrote:

Also etymology somewhat contradicts my proposal: https://github.com/lojban/jbovlaste/issues/131 where we have etymology only in Lojban whereas for the other languages they can be generated by third party software like those that produce printable dictionaries.

Uh, what are they generating from, then?

As I understood in this proposal for every language there is a separate entry with etymology. All such entries can be autogenerated from Lojban one.

I'm not certain whether Naours suggest there should be one etymology field for each definition.

I can imagine a case where two experimental cmavo or gismu would have two distinct and incompatible definitions, along with two unrelated source/etymology, although that seems to be a pretty uncommon case.

On the other hand, copying manually the etymology field to each definition would be a boring task, if not a chore.

Another option would be to have definitions grouped by proposed meaning (each of those meaning groups would probably be restricted to one definition entry per language), and have one etymology field attached to each proposed meaning group, so as to avoid redundancy.

[Gleki Arxokuna]

2015-05-28 19:20 GMT+03:00 Ilmen <ilmen....@gmail.com>:

On 28/05/2015 16:56, Gleki Arxokuna wrote:

Also etymology somewhat contradicts my proposal: https://github.com/lojban/jbovlaste/issues/131 where we have etymology only in Lojban whereas for the other languages they can be generated by third party software like those that produce printable dictionaries.

Uh, what are they generating from, then?

As I understood in this proposal for every language there is a separate entry with etymology. All such entries can be autogenerated from Lojban one.

I'm not certain whether Naours suggest there should be one etymology field for each definition.

I can imagine a case where two experimental cmavo or gismu would have two distinct and incompatible definitions, along with two unrelated source/etymology

yes, issue 131 says that etymology is bound to meaning, not word.

 

, although that seems to be a pretty uncommon case.

On the other hand, copying manually the etymology field to each definition would be a boring task, if not a chore.

Another option would be to have definitions grouped by proposed meaning (each of those meaning groups would probably be restricted to one definition entry per language), and have one etymology field attached to each proposed meaning group, so as to avoid redundancy.

mi'e la .ilmen. mu'o

[Ilmen]

coi ro do

As per Naours' request, I will submit a Lojban dictionary definition
style guidelines proposal to BPFK's vote.

Here is the proposal draft:

•
http://mw.lojban.org/papri/BPFK_style_guidelines_for_Lojban_dictionary_definitions_%28proposal_draft%29

Please feel free to correct any outright mistake, suggest improvements
or discuss its content.

I hope we'll be able to open a vote on adopting those guidelines if
there is enough interest and support for this proposal among the BPFK
members.

[Pierre Abbat]

On Friday, July 24, 2015 13:34:24 Ilmen wrote:
> coi ro do
>
> As per Naours' request, I will submit a Lojban dictionary definition
> style guidelines proposal to BPFK's vote.
>
> Here is the proposal draft:
>
> •
> http://mw.lojban.org/papri/BPFK_style_guidelines_for_Lojban_dictionary_defin
> itions_%28proposal_draft%29
>
> Please feel free to correct any outright mistake, suggest improvements
> or discuss its content.

As to French, when I look up a French noun in a French dictionary, usually the
definition does not begin with an article, whereas a definition of an English
word in an English dictionary usually does. However, in French sentences, a
noun phrase normally does have an article, whereas in English often it
doesn't. That's because French has three types of article: definite, indefinite,
and partitive. The partitive article (which is "de" usually followed by the
definite, with the usual contractions) is used in most cases where English uses
no article (sometimes French uses the definite where English uses none). The
paragraph on the page should have examples in French, including some with the
partitive article.

Pierre
--
ve ka'a ro klaji la .romas. se jmaji