JSON Return: All Objects Wrapped in Array?

Having played with your API for just a week or so, I confess I'm really impressed!

One thing, though, that's driving me nuts is the JSON serialization of the delivered object. It appears you wrap everything in a list/array structure - whether it's single element or not!

While I'd guess this might have been done for the sake of consistency - I'm not quite sure it solves as many problems as it creates. It'd be really nice if there was a fix - or potentially a 'shape' definition of the response object in our metadata. Like a mini 'WSDL' so to speak.

Regards,

My use case is synonym clustering.

Comments

  • AmosDuveenAmosDuveen Member, Administrator, Moderator admin

    Hi @yaquino337,

    Thanks for the feedback, I'm glad you like it.

    You are right in your deduction that the structure is as it is because of the need for consistency. However, you may not fully appreciate just how important consistency is to the work we do, only some of which is currently surfaced through the API at the moment (more coming, as and when it is available, of course). The core of this part of the business is to support people who want to work with datasets across multiple languages; the reason people come to us is precisely because we can provide that level of consistency which allows them to significantly reduce the time they must spend in, and the cost of, developing each new dataset.

    What you see surfaced through the API has either been developed for those licensees (e.g. Spanish, Hindi) or through our Oxford Global Languages (OGL) program (e.g. isiZulu/English, Northern Sotho/English). In both cases, there is a strong need for consistent data, meaning that, by the time it gets to the API, it's in a pretty uniform structure which may not always suit the content but which better suits the multi-lingual developers it was designed for. However, were we to produce datasets in isolation (as used to happen) that might be fine for someone only developing a single dataset but it would be an utter pain in the [insert preferred body part here] for anyone trying to develop across multiple datasets. Ergo, the focus on consistency is the most practicable solution across all of our user base.

  • shahoodshahood Member ✭✭

    @AmosDuveen

    In that case, shouldn't u at least mention whether an array is actually an array (can contain more than one object) or it is a single object that's just wrapped up in an array, for the sake of consistency?
    Now for example, the array "thesaurusLinks", would it ever contain more than one objects? If no, it can be mentioned in documentation, so that developers don't have to perform an unnecessary loop to find if there are any more objects in there.

  • AmosDuveenAmosDuveen Member, Administrator, Moderator admin
    edited May 2018

    Hi @shahood,

    As for the thesaurus links, I can imagine hypothetical instances where it might be the case that more than one link is included but I don't think that's the reason. I think it is more likely to be a legacy of the conversion since the data was not originally formatted in JSON and therefore might not be quite as smooth as native JSON data; however, that is still a lot better than having to start a new dictionary in a new format from scratch, which might itself need to be converted to some other format ten years down the line.

  • shahoodshahood Member ✭✭
    edited May 2018
    Hi @AmosDuveen

    Don't know what gave u the idea that I don't like your data. If u r not open to suggestions, u should make it clear on ur website instead of being rude to the users at random occasions.

    I never suggested u to change ur dictionary. The suggestion was to just mention the fact in the docs that an apparent array actually is there for the sake of consistency and will hardly contain more than one object....that's just to make it a bit easier for the developers.
  • AmosDuveenAmosDuveen Member, Administrator, Moderator admin
    edited May 2018

    Hi @shahood,

    It's not that we aren't open to improving our data, it is that there are lots of competing priorities to be considered by our language technologists. If something hasn't been addressed that you think ought to be, it is usually for one of two reasons: 1, whatever it is just isn't possible; or 2, it isn't practical.

    Your issue very much falls into the latter category. A change like that would require a change to the schema. I won't bore you with an exposition on schema/DTD management issues that such a change would cause, save to say that it then has a knock-on impact on every other dataset in our ODAPI JSON format; we would then need to review our conversion processes to make sure that future datasets meet the updated schema; potentially, we would also need to reconvert all our other datasets if we don't want the schema to get so loose as to become meaningless through lots of small changes of this kind.

    Ultimately, this would be an extremely high effort, high risk change that leads to very little benefit, even for the developers using our data. That is why you are unlikely to see it change any time soon.

  • shahoodshahood Member ✭✭
    edited May 2018
    Pl go through my suggestion again in ur free time. Somehow I have failed to make u understand that properly.
Sign In or Register to comment.