Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve transitivity data #32

Open
GoogleCodeExporter opened this issue Mar 4, 2015 · 14 comments
Open

improve transitivity data #32

GoogleCodeExporter opened this issue Mar 4, 2015 · 14 comments

Comments

@GoogleCodeExporter
Copy link

Currently, the transitivity information is all guesswork. For this reason, it 
is hidden behind a preference, and when it is display it is shown at the bottom 
in a smaller font, and is labeled "best guess".

This issue is a request to improve the transitivity data to the same quality as 
the rest of the data, and then display it next to the verb where it would 
normally be in a dictionary, using less technical language than is used now.

(Since MO never gave us transitivity information directly for any of the verbs, 
this task seems like it might be impossible. But maybe we can come up with a 
solution like get together a dozen of the most skilled speakers and have a 
vote. The result would still be a guess, but it'll be an educated guess or 
consensus rather than entirely my own guess.)

Original issue reported on code.google.com by De.vID.jonpIn on 11 Jan 2013 at 8:24

@GoogleCodeExporter
Copy link
Author

There are many verbs for which we do not need to guess, when there is a canon 
example. e.g. {qalegh} has the object "you", so according to the generel 
definition of transitivty it IS 100% transitive. No vote or discussion needed.

Then, there are other where we also know they are intransitive, like those of 
"state or quality": Doq "be red" can never take an object - at least in 
english, so this "best guess" is certainly a "very good" guess.

Now, there remain verbs where we really can only guess from the english point 
of view, like {Qong} "sleep" is unlikely to take an object - but we cannot be 
sure, of course (?)

In my dictionary, transitivity is displayed using either (vt.) or (vi.) and 
just (v.) if "unknown".

My suggestion is - in the first step - to remove the standard-note "best guess" 
and only note it where it really is a guess when the situation is unsure.

Sop, v. eat
transitive: yes

Qong, v. sleep
transitive: probably no (best guess)




Original comment by Lieven.l...@gmail.com on 11 Jan 2013 at 9:58

@GoogleCodeExporter
Copy link
Author

I have no means of tagging individual entries with shades of certainty. 
Whatever I apply, it will be to the entire class, of which there are five: 
ambitransitive (both), intransitive, stative (intransitive and is a state or 
quality), transitive, and unknown.

Examples:
ambi - {So'}, {meQ}
intransitive - {chung}, {Duv}, {nga'chuq}, {ron}
stative - {belHa'}, {'ugh}
transitive - {bom}, {legh}, {Sov}
unknown - {bachHa'}

I can say that all of the "ambi" ones are certain, because I only tag a verb as 
such if there are definitions or examples for both transitive and intransitive 
uses.

I do not know that entries tagged "intransitive" are actually intransitive. Can 
one say "sleep a good sleep"? {yIn} is transitive, so why not {Qong}? There are 
disagreements: I believe {lol} may be transitive ("be in a [name of stance] 
martial arts stance"), but this is an interpretation and others have disagreed, 
so it's tagged as "intransitive".

Most of the verbs tagged "transitive" probably are, based on their definitions, 
but for many verbs we don't have canon examples of usage.

The stative ones are interesting. They're intransitive, but also defined in a 
way ("to be [in some state], to have [some quality]") that makes them almost 
certain to be intransitive. So I'm more sure about these ones than the 
intransitive ones (but still not 100% sure).

The unknown ones are just that, unknown. This is the default if I haven't 
marked a verb as anything else.

I can't easily do what you suggest and treat individual verbs differently, like 
{Sop} and {Qong}, because that would require individually annotating each verb 
with a degree of certainty, rather than treating an entire class the same way.

Original comment by De.vID.jonpIn on 11 Jan 2013 at 10:32

@GoogleCodeExporter
Copy link
Author

Also, I should mention that the difference between "ambi" and "transitive" is 
that whereas "transitive" verbs can always not have an object, the "ambi" verbs 
change their meaning depending on whether there is an object.

For example: {meQ} means "to burn, be burning" (the subject is burning) when 
there is no object, but "to burn, set something on fire" (the object is 
burning) when there is one. That is, {meQ-1} is intransitive, and {meQ-2} is 
transitive and means {meQ-1-moH}. :-)

Original comment by De.vID.jonpIn on 11 Jan 2013 at 10:35

@GoogleCodeExporter
Copy link
Author

De'vID:
"I have no means of tagging individual entries with shades of certainty. 
Whatever I apply, it will be to the entire class,... "

I think it might be possible if you just add a few classes, so you can 
distinguish between:
 class = "definitely transitive because there is a canon example"
and
 class = "I guess this is transitive because it makes sense to me, but it's not certain"
etc.

With this, no rule is broken and users do have even more correct information. 
"Best guess" has a negative connotation (at least for me), always made me think 
like "why is this a guess that legh is transitive? Are there any doubts?"

Original comment by Lieven.l...@gmail.com on 11 Jan 2013 at 12:43

@GoogleCodeExporter
Copy link
Author

The suggested solution of adding more verb classes is a bad idea, from a 
software engineering perspective. The verb class and the degree of certainty 
about it are orthogonal pieces of data, and should not be represented using one 
data structure. 

If we divide transitive verbs into two classes, then in every single place in 
the code where such verbs are handled, the code has to be aware of both 
classes. This has side effects. For example, right now it's easy to return a 
list of (Klingon word order) sorted transitive verbs. If the class is split 
into two, then to get a list of transitive verbs the two sublists have to be 
merged and sorted. This introduces complexity where none existed before. And 
there may be side effects that we can't anticipate. A feature of the correct 
solution to this issue must be that if I change a verb from 
"transitive-uncertain" to "transitive-certain", any code which is concerned 
only with transitivity (and not with certainty) must not have to be modified.

So the suggested solution isn't the right one. The correct solution is to 
somehow add the ability to tag individual entries with annotation about 
certainty which is orthogonal to verb class.


Original comment by De.vID.jonpIn on 12 Jan 2013 at 6:47

@GoogleCodeExporter
Copy link
Author

Also: Some members of the KLI believe that Klingon transitivity doesn't work 
the same way as in English, and that all Klingon verbs are in fact what we 
would call transitive. This is another reason why I put the transitivity 
information in a less accessible place, because some Klingonists consider 
transitivity not to apply to Klingon at all.

Original comment by De.vID.jonpIn on 12 Jan 2013 at 7:00

@GoogleCodeExporter
Copy link
Author

Okay, I'm just giving suggestions from a user's view, but you are the 
programmer. :-)

I now think/agree it's better to leave the line as it is. What do you think 
about adding an extra line, which says "canon example is given", or the like? 
(basically it's the same as the certainty thing, but the classes can remain as 
they are and it's more neutrally based on canon)

It would look like

----------------------------
Sop v. eat
Transitivity (best guess): transitive
guess based on canon: yes
----------------------------

By the way, you did not yet answer the question on replacing "in/transitive" by 
"yes/no". That's just an optical issue though, not important.

Original comment by Lieven.l...@gmail.com on 12 Jan 2013 at 10:17

@GoogleCodeExporter
Copy link
Author

I think your earlier suggestion is good in term of the information conveyed to 
the user, but just not in the way you suggested it be implemented.

I'll add an additional annotation that the verb's transitivity is confirmed by 
canon. That way the output will be very close to your earlier suggestion (even 
if internally it isn't represented that way). When the entry is displayed, the 
program will check both the transitivity and the certainty, and the messages 
can be very close to what you requested.

transitive and known -> "This verb can take an object."
transitive and unknown -> "This verb can probably take an object, but this is 
not known."
intransitive and known -> "This verb cannot take an object."
intransitive and unknown -> "This verb probably cannot take an object, but this 
is not known."
stative (should always be known) -> "This verb describes a state or quality and 
cannot take an object."
ambitransitive (should always be known) -> "This verb can take an object. When 
it does, it changes in meaning."
unknown -> (display no information)

I'm not sure about the exact wording yet but something like this can be done, 
and the outcome is very close to what you asked.

Of course, to implement the above, we'd have to annotate all the verbs for 
which transitivity is known from canon (example or definition).

Original comment by De.vID.jonpIn on 13 Jan 2013 at 8:00

@GoogleCodeExporter
Copy link
Author

Nice - DaH wa' DoS wIqIplaw' :-)

For "unknown" there should be a note anyway, e.g. "nothing is known about 
transitivity." - just for not confusing the user.

Original comment by Lieven.l...@gmail.com on 13 Jan 2013 at 6:15

@GoogleCodeExporter
Copy link
Author

Original comment by De.vID.jonpIn on 20 Jan 2013 at 5:05

@GoogleCodeExporter
Copy link
Author

Beginning in revision 7192bc05f94c transitivity can be marked as confirmed.

Original comment by De.vID.jonpIn on 25 Jan 2013 at 9:38

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

Beginning in revision 7192bc05f94c transitivity can be marked as confirmed.

Original comment by De.vID.jonpIn on 25 Jan 2013 at 9:38

@GoogleCodeExporter
Copy link
Author

Strings updated in revision 0db5bd1c4f86.

Original comment by De.vID.jonpIn on 26 Jan 2013 at 11:35

@GoogleCodeExporter
Copy link
Author

The transitivity data seems to be fairly good at this point. I'm making showing 
them the default behaviour for the program.

Original comment by De.vID.jonpIn on 2 Dec 2014 at 10:43

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant