lakaara-output suggestion

[vvasuki]

drdhaval2785/prakriya#37 (comment) इति धवलाविनाशाभ्यां चर्च्यमाने -

(+ @avinashvarna)

द्वे परिवर्तनय् औचित्यं भजेते -

[
{
'dhaatu':  u'10.0382',
'arthaH': 'अवकल्कने मिश्रीकरण इत्येके चिन्तन इत्यन्ये',
'ruupANi': {u'mas': [u'BAvayAmaH'], u'sip': [u'BAvayasi'], ...}
},
{
'dhaatu':  u'10.0277',
'arthaH': 'प्राप्तौ',
'ruupANi': {u'mas': [u'BAvayAmaH'], u'sip': [u'BAvayasi'], ...}
},
...
]

एवं उत्तमस्तरे "श्रेणी"-प्रयोगः ({…} इत्यस्य स्थाने […]), अर्थस्यान्तर्भावश्च।
तदितोऽपि सौकर्याय भवति।

[avinashvarna]

'dhaatu' इत्यस्य स्थाने 'sankhyaa' इत्यपि भवितुम् अर्हति । यतो हि प्रक्रियायां तथैव दर्श्यते ।

[vvasuki]

युक्तं तत्। इतोऽपि परिष्कृत्य (ruupaaNi -> law) -

[
{
'sankhyaa':  u'10.0382',
'arthaH': 'अवकल्कने मिश्रीकरण इत्येके चिन्तन इत्यन्ये',
'law': {u'mas': [u'BAvayAmaH'], u'sip': [u'BAvayasi'], ...}
},
{
'sankhyaa':  u'10.0277',
'arthaH': 'प्राप्तौ',
'law': {u'mas': [u'BAvayAmaH'], u'sip': [u'BAvayasi'], ...}
},
...
]

इति रोचते।

[drdhaval2785]

Seems good idea.

[drdhaval2785]

How about the following?

{
  '10.0382':{
            'verb':  'BU',
            'verbwithoutanubandha': 'BU',
            'meaning': 'avakalkane miSrIkaraRa ityeke cintana ityanye',
            'gana': 'curAdiH',
            'law': {u'mas': [u'BAvayAmaH'], u'sip': [u'BAvayasi'], ...}
            'liw': ...,
            'luw': ...,
            .... (All other lakaras)
  },
  '10.0277':{
            'verb':  'BU',
            'verbwithoutanubandha': 'BU',
            'meaning': 'prAptO',
            'gana': 'curAdiH',
            'law': ...,
            'liw': ...,
            'luw': ...,
            .... (All other lakaras)
  },
}

[drdhaval2785]

@avinashvarna and @vvasuki Rather than iterating each list item to see whether this is the required verb number, it would be good to keep it as the key of dict.
Verb number is in a way unique. The forms verb, verbwithoutanubandha, gana all can be same, but verb number can not be. Therefore it makes sense to keep it as key (to fetch other verb related information like seT/aniT, parasmaipadI/AtmanepadI etc.)

[drdhaval2785]

UPDATE:
Please see the additional 'padI' and 'it' fields.

{
  '10.0382':{
            'verb':  'BU',
            'verbwithoutanubandha': 'BU',
            'meaning': 'avakalkane miSrIkaraRa ityeke cintana ityanye',
            'gana': 'curAdiH',
            'padI': 'uBayapadI',
            'it': 'sew',
            'law': {u'mas': [u'BAvayAmaH'], u'sip': [u'BAvayasi'], ...}
            'liw': ...,
            'luw': ...,
            .... (All other lakaras)
  },
  '10.0277':{
            'verb':  'BU',
            'verbwithoutanubandha': 'BU',
            'meaning': 'prAptO',
            'gana': 'curAdiH',
            'padI': 'uBayapadI',
            'it': 'sew',
            'law': ...,
            'liw': ...,
            'luw': ...,
            .... (All other lakaras)
  },
}

[vvasuki]

Good ideas here - although I still think that we should have a list at the top level as suggested in #17 (comment) . That way consumers can define a uniform JSON schema and use common libraries to parse this into a list of objects without needing to add custom parsing code.

A couple of other quibbles:

• dhaatu is a verb root, not a verb. So replace verb with dhAtu
• verbwithoutanubandha -> niranubanDa_dhAtu (generally, while squishing words together follow either the python or camelCase convention for readability)

[vvasuki]

Another general suggestion is to include fields which identify the class of data being presented - such as "jsonClass": "TinantaForms" or "jsonClass": "LakaaraForms" within every json object. This will again enable easy use of JSON parsing libraries to read these strings on native objects (not dicts or maps) in a variety of languages.

[drdhaval2785]

uniform JSON schema

True. Good point.

[drdhaval2785]

Another general suggestion is to include fields which identify the class of data being presented - such as "jsonClass": "TinantaForms" or "jsonClass": "LakaaraForms" within every json object. This will again enable easy use of JSON parsing libraries to read these strings on native objects (not dicts or maps) in a variety of languages.

Didnt understand anything of what you said. Can you elaborate on what you have in mind. My exposure to other languages is quite primitive.

[vvasuki]

Didnt understand anything of what you said. Can you elaborate on what you have in mind. My exposure to other languages is quite primitive.

There were two parts to what I said in that paragraph:

• What should you do?
• Why you should do it?

The "what" part is clear I guess - but just in case, I elaborate with an example: https://api.vedavaapi.org/scala/grammar/v1/analyser/hareH yields a list of stuff like:

{
"jsonClass": "Analysis",
"subanta": {
"jsonClass": "Subanta",
"vibhakti": {
"jsonClass": "SupVibhakti",
"vibhaktiNum": 5
},
"vachana": 1
}
}

Observe the jsonClass fields above. I am suggesting that you include such a field wherever you see {} in your output.

Now the 'why' part: I can use it with standard json parsers (eg. a customized version of jsonpickle in python, or json4s in scala) to read this string into a native object. In python, I can then do: analysis.subanta.vibhakti.vibhaktiNum rather than analysis["subanta"]["vibhakti"]["vibhaktiNum"], and more importantly, I can define methods like: analysis.subanta.matches(some_tinanta) etc.. Similarly in other languages.

[drdhaval2785]

https://pypi.org/project/python-box/ easier way to do than adding a lot of jsonClass in the data ifself? @vvasuki?

[vvasuki]

https://pypi.org/project/python-box/ easier way to do than adding a lot of jsonClass in the data ifself? @vvasuki?

True in a constrained sense. It won't help for the following cases:

• JSON to object converters in most non-Python languages.
• Adding special methods to each class - for example, isValid() to the Subanta class.

It costs next to nothing to add the jsonClass here and throw it away if one doesn't need it downstream.