Markup Structure for Song/Group Pages

[PiperBaron]

The songs themselves (both the original Korean lyrics and the translations) will be within one page. The groups and list of members will have their own dedicated pages that will be linked to the lyrics. None of this is totally set in stone, we can change/adjust things if we need to.

Song/Lyric Structure

• About
  • Background info on the song itself
    • Meaning/themes (as stated by the artists themselves -- pulled from interviews), how the song was written/came to be, etc.
  • Name of the album it belongs to (or specifying if its a single)
  • Composer/producer credits
    • Link to group members/group page if they happen to be included in the list
  • Release date
  • Label/Company
  • (Optional -- only include if applicable) Current number of music show wins
    • Maybe this can Billboard ranking as well
• Lyrics
  • Original Korean lyrics and translations will be contained in their own elements
    • Intro (if there is one), Verses, Choruses, Pre-Choruses, the Bridge, and Outro (again, if there is one)
      • All of these elements will be numbered and contain the individual lines sung/rapped/spoken, with a reference to the xml:id of the member(s) performing them --> each reference can link to that specific member's entry in their group page
      • We'd include backing vocals/ad libs as well

Group/Members Structure

• Background info on the group itself
  • The label/company they're under
  • Debut date and song
  • How the group was formed (some groups are just hand-selected by the company, some are formed through survival-style TV shows, etc.)
  • General overview of their discography (listing albums, mix-tapes, singles)
  • Maybe include their brand reputation ranking in Korea (??)
    • We could demonstrate if there's a disparity in popularity of a group internationally vs in Korea -- for example, GOT7 is very popular and well-known in Western/international K-Pop circles, but they aren't even in the top 50 of all (boy and girl) K-Pop groups in South Korea
• Each member will get their own entry listing out basic information
  • Stage/Birth/Korean name
    • Include both original Hangul and romanization for Korean names. For non-Korean birth names, again include the name in its original language/writing system and the romanization. Example for a Chinese birth name: 黄仁俊/Huang Renjun (they would be in their own elements)
  • Role/Position (Main Vocal, Sub Rapper, Dancer, etc.) --> Specify here if they compose/produce for the group
    • We could possibly have some sort of small dictionary that defines these terms? (Just an idea)
  • Sub-units (especially relevant for NCT, Seventeen, and Stray Kids)
  • Height, Weight, Birthday, etc.
  • Social media links (?)

[ebeshero]

@PiperBaron Wow! Lots of data to organize here! I'm eager to see how you and @AreannaRussell decide to structure the lyrics markup. It looks like you're organizing lyrics by artist/group. I like the idea of investigation comparative popularity in different locations. Do you have access to English/French translations or summaries over fan sites?

[PiperBaron]

@ebeshero For translations, definitely -- there's translations for each of these songs in most popular languages! As for popularity, that can be a difficult thing to quantify in the K-Pop community, given that so much of the participation in fan-culture is done anonymously online. I'll do some research and see if I can find more data like the Twitter mention analysis that we found earlier.

[ebeshero]

@PiperBaron Just responding to your Slack post here. Okay: My point about having one schema was mostly that you don't want you and @AreannaRussell to be making two different schema for coding the same kinds of files (as in each of you creates your own independent modeling of the same thing). Sometimes people start out doing that on a project and it causes all kinds of problems later as we start trying to process the code to "pull" information and produce website material for the project.

But what you describe is different from that. Your project would have two very different kinds of XML documents, almost certainly stored in different directories (file folders), even. So for that, it is perfectly okay to create two different schemas, one for each kind of document. Just be sure you name these clearly and it's easy to know which schema should be associated with which set of XML documents. That's where careful file directory structure in your GitHub repo will help.