jmdict
2289030
Active
(id:
2151386)
<entry id="2151386" stat="A" corpus="jmdict" type="jmdict">
<ent_corp type="jmdict">jmdict</ent_corp>
<ent_seq>2289030</ent_seq>
<k_ele>
<keb>or</keb>
</k_ele>
<k_ele>
<keb>OR</keb>
</k_ele>
<r_ele>
<reb>オア</reb>
</r_ele>
<sense>
<pos>&conj;</pos>
<gloss>or</gloss>
</sense>
<sense>
<stagk>OR</stagk>
<pos>&n;</pos>
<field>&logic;</field>
<gloss>OR (Boolean operator)</gloss>
</sense>
<info>
<audit time="2008-05-24 00:00:00" stat="A">
<upd_detl>Entry created</upd_detl>
</audit>
<audit time="2012-05-11 04:30:32" stat="A" unap="true">
<upd_name>Marcus</upd_name>
<upd_refs>daijs</upd_refs>
<upd_diff>@@ -8,0 +8,4 @@
+<pos>&conj;</pos>
+<gloss>or</gloss>
+</sense>
+<sense></upd_diff>
</audit>
<audit time="2012-05-11 05:07:22" stat="A">
<upd_uid>jwb</upd_uid>
<upd_name>Jim Breen</upd_name>
<upd_email>...address hidden...</upd_email>
</audit>
<audit time="2018-09-30 14:37:09" stat="A" unap="true">
<upd_uid>robin1354</upd_uid>
<upd_name>Robin Scott</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>Sense 2 is usually written "OR". I suggest creating a separate entry for it.</upd_detl>
</audit>
<audit time="2018-09-30 19:23:54" stat="A">
<upd_uid>rene</upd_uid>
<upd_name>Rene Malenfant</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>i agree. but i'm not sure the "conjunction" one is worth recording at all. (and am i'm not convinced it's a conjunction) does it ever appear on its own outside of compounds?
the OR sense was the original, so I'm just going to add the headword here and propose a new entry for the other sense</upd_detl>
<upd_diff>@@ -3,0 +4,3 @@
+<k_ele>
+<keb>OR</keb>
+</k_ele>
@@ -7,4 +9,0 @@
-<sense>
-<pos>&conj;</pos>
-<gloss>or</gloss>
-</sense></upd_diff>
</audit>
<audit time="2018-09-30 19:37:14" stat="A">
<upd_uid>robin1354</upd_uid>
<upd_name>Robin Scott</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>Aligning format with NOR entry. Not just a computing term.</upd_detl>
<upd_diff>@@ -12,2 +12 @@
-<field>&comp;</field>
-<gloss>OR</gloss>
+<gloss>OR (boolean operator)</gloss></upd_diff>
</audit>
<audit time="2018-10-03 02:16:04" stat="A" unap="true">
<upd_uid>jwb</upd_uid>
<upd_name>Jim Breen</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_diff>@@ -6,0 +7,3 @@
+<k_ele>
+<keb>or</keb>
+</k_ele>
@@ -10,0 +14 @@
+<stagk>OR</stagk>
@@ -13,0 +18,4 @@
+<sense>
+<pos>&conj;</pos>
+<gloss>or</gloss>
+</sense></upd_diff>
</audit>
<audit time="2018-10-03 04:35:44" stat="A" unap="true">
<upd_uid>Marcus</upd_uid>
<upd_name>Marcus Richert</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>I propose moving the conj sense back up on top, as I think it's likely more common. Not sure we really need the restr for the
operator.</upd_detl>
<upd_diff>@@ -13,0 +14,4 @@
+<pos>&conj;</pos>
+<gloss>or</gloss>
+</sense>
+<sense>
@@ -18,4 +21,0 @@
-<sense>
-<pos>&conj;</pos>
-<gloss>or</gloss>
-</sense></upd_diff>
</audit>
<audit time="2018-10-03 09:37:25" stat="A">
<upd_uid>robin1354</upd_uid>
<upd_name>Robin Scott</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>Yes, I agree with this order.
The operator sense is always capitalised so I think the restriction is appropriate.</upd_detl>
<upd_diff>@@ -5 +5 @@
-<keb>OR</keb>
+<keb>or</keb>
@@ -8 +8 @@
-<keb>or</keb>
+<keb>OR</keb></upd_diff>
</audit>
<audit time="2021-10-12 16:53:52" stat="A">
<upd_uid>robin1354</upd_uid>
<upd_name>Robin Scott</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_diff>@@ -19,0 +20 @@
+<field>&logic;</field></upd_diff>
</audit>
<audit time="2021-10-13 23:38:22" stat="A">
<upd_uid>robin1354</upd_uid>
<upd_name>Robin Scott</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_diff>@@ -21 +21 @@
-<gloss>OR (boolean operator)</gloss>
+<gloss>OR (Boolean operator)</gloss></upd_diff>
</audit>
</info>
</entry>