Initial schema discussion

WithoutPants commented 4 years ago

Lifting graphql types from the original stash schema:

Performer

type Performer {
  id: ID!
  name: String
  gender: String
  url: String
  twitter: String
  instagram: String
  birthdate: String
  ethnicity: String
  country: String
  eye_color: String
  height: String
  measurements: String
  fake_tits: String
  career_length: String
  tattoos: String
  piercings: String
  aliases: [String!]!
}

Notes:

Added gender field. This should probably be an enum of values.
height should probably be a standardised field.
measurements needs to be made less ambiguous
fake_tits should probably be made into an enum (Y/N/NA)
career_length could probably be made into two fields - start and end year
made aliases a list of strings
how do we handle multiple performers with the same name?

Studio

type Studio {
  id: ID!
  name: String!
  url: String
}

Tag

type Tag {
  id: ID!
  name: String!
  description: String
}

Notes:

added description
while the schema can be generalised, the curation of tags should be carefully controlled, in my opinion. We'd need to determine a list of (as best as possible) objective tags.

Scene

type Scene {
  id: ID!
  title: String
  details: String
  url: String
  date: String

  studio: Studio
  tags: [Tag!]!
  performers: [Performer!]!
  checksums: [String!]
}

Notes:

added checksums. Allows multiple files to point at the one scene. May want to consider adding filename information to the checksum as well.

Leopere commented 4 years ago

Some people have mentioned that several studios have parent studios and some performers also have aliases how do we want to manage these scenarios?

Leopere commented 4 years ago

Checksums could also be FFMPEG Fingerprints.

WithoutPants commented 4 years ago

Some people have mentioned that several studios have parent studios and some performers also have aliases how do we want to manage these scenarios?

Performer aliases is covered in the schema above already. My suggestion would be to have a single primary name for each performer and a list of aliases as per the schema. I'll look into #115 and suggest a schema accordingly.

WithoutPants commented 4 years ago

A decision also needs to be made about performer and studio images. I could split this off into a separate issue, but it does impact the schema.

My main concern regarding both is the possibility of copyrighted or illegal images making their way into the database. If we make the decision to allow them, then they would need to be carefully controlled. Including images also increases the storage space and upload/download throughput.

Leopere commented 4 years ago

The primary name should be their real name I would imagine as that is the baseline. However in scenarios where there is no Real Name that should also be acceptable and not considered invalid.

*Edit Now that I think about the idea of a Primary name vs Secondary name that should be reasonable as well however we should have a database defined difference between the real name and aliases and then whatever their predominant or primary name is.

ghost commented 4 years ago

Regarding images. I think studio images are fine, even Wikipedia allows copyrighted logos since it's considered fair use. I also doubt any studio would object to anyone showing their logo.

Actor images are obviously more difficult. My take is that promotional images are fine, as long as we link back to the owners. I don't know specifically how indexxx and freeones solve this, but it seems something along these lines. The same logic applies for scenes, a lot of studios make cover images specifically for these kinds of purposes, like met-art, etc.

With all that said, I don't think hosting images should be a priority since there are technical issues to think through. If we just add a image_url field people can host images on imgur/vidble or just hotlink directly to the publishers, and we sidestep the entire issue.

Leopere commented 4 years ago

Yes, hosting images is something I really want. I want to target here however we should consider how it should be done as it will be relevant for helping with tagging. Even if we just pull the data from someone else's database or push it through some other CDN.

iamjen023 commented 4 years ago

ok so now that im on my pc i can port over what i talked about in discord

for performers

male `type Performer { id: ID! name: String gender: String url: String twitter: String instagram: String birthdate: String ethnicity: String country: String eye_color: String height: String measurements: String career_length: String tattoos: String piercings: String aliases: [String!]! cock_piercings: String sack_piercings: String cock_size: number in cm cock_circumstance: number in cm Head_type: String Other_cock_charactistics: String Ball_size: String sack: String

}`

for trans

type Performer { id: ID! name: String gender: String url: String twitter: String instagram: String birthdate: String ethnicity: String country: String eye_color: String height: String measurements: String fake_tits: String career_length: String tattoos: String piercings: String aliases: [String!]! cock_piercings: String sack_piercings: String cock_size: number in cm cock_circumstance: number in cm Head_type: String Other_cock_charactistics: String Ball_size: String sack: String status: String --preop postop }

Orthodox-531 commented 4 years ago

Would it make sense to implement a structure for storing the types of content the performer is known to participate in?

Additionally, an enum of IDs for other major reference sources, like IAFD, might be useful.

stashapp / metadata-api-discuss