search

bdarcus / csl-next-attic

a very tentative experiment ATM ...
2 stars 0 forks source link

Should the input schema allow for multilingual data? #12

Open denismaier opened 1 year ago

denismaier commented 1 year ago

At least at some point, probably yes. Question is, if there's anything we should already do now.

bdarcus commented 1 year ago

I'm thinking there are a lot of details to think about with input schema. This, but also do we do related relations, as Hayagriva (which seems well-designed) does?

Aside: I also find it interesting they obviously also struggled with the concision vs correctness issue, and allow both. So authors can be strings.

But I'm thinking to establish the initial basis for conversion, I'm not going to worry about any of this; just figure out enough to render a simple book!

Make sense?

denismaier commented 1 year ago

Makes sense!

On Hayagriva: I find it interesting that they allow some fields to be plain strings, or complex fields with subfields:

publisher: UN World Food Programme

vs.

publisher:
    value: imagiNary Publishing
    title-case: Imaginary Publishing
    sentence-case: imagiNary publishing
bdarcus commented 1 year ago

Exactly! Same with authors.

I'm thinking to invite them to the conversation; maybe we can borrow some of these ideas.

They don't have a schema, for example!

I committed this file for now, though the schema doesn't reflect it and not sure it's a good idea:

---
citekey1:
  title: A Book
  # A string option below.
  #
  # This raises a HUGE can-of-worms:
  #
  # Can a contributor be an object, a string, OR a list?
  # Or must we choose only one, which necessarily means a list of objects?
  # But that's an awfully heavy-solution for many cases.
  #
  # But let's leave that aside for now.
  author: Doe, Jane 
  issued: "2020" # because dates here are (EDTF) strings
  ## Again: an object, string, or a list of objects, or only the last?
  publisher: 
    name: ABC Books
    location: New York

Either way, the final version for discussion will not be much more complex.

bdarcus commented 1 year ago

On Hayagriva: I find it interesting that they allow some fields to be plain strings, or complex fields with subfields:

Playing with an idea on this (section at the end; though personal names represent contributor objects):

https://github.com/bdarcus/csl-next/blob/main/csl-next.md#input-data-types

Edit: that probably won't work actually.

bdarcus commented 1 year ago

I like the Hayagriva design in general, BTW.

I do wonder how they deal with corporate names though.

    author:  ["Mehta, Jiten", "United Nations, Some subunit"]