jasrys / cwr-json Goto Github PK

Currently the description is for US only registrations

And enforced to 12 chars which might not work for all countries

See #48

It starts with rightsholders and goes down from there. Gone is the concept of SPUs, SWRs etc.

Probably shouldn't have an array property. May need some validation and required fields added

Only required for UK societies. Might be difficult to enforce this conditional requirement in the schema itself

Isn’t it the case that a Writer can only have one Manuscript Share? If so, there is really no reason to have a separate MAN record since the the relevant MAN properties (pr, mr, and sr manuscript shares) are really just properties of the Writer. Suggest removing the MAN record and bringing the pr, mr, sr manuscript shares “up a level” to the writer. We can also ditch the writer_ip_number since that’s already defined at the writer level

probably should have a recursive array

The INS record seems to only contain information about the WRK itself, nor does it seem possible for there to be multiple INSs for a given WRK. There does not appear to be a need for nested separate record hanging off of the WRK. We could just “pull up” the relevant INS properties to the WRK level

required for UK societies, is it actually used though?

A schema was added to the JSON spec, but I can't find it referenced in the EDI spec

Have not reviewed yet

Someone mentioned situations where a writer might not have a publisher or vice versa as allowable, valid use cases

some opus numbers are really really long, more than 25 chars

It appears from the validation rules that the only valid values for this record are “Y”, “N”, or “U” which could be handled with a boolean (i.e. true, false, or null for the “unknown” case). If we switch it to a boolean, we should remove the mandatory requirement to allow for the null/unknown case. We could also consider changing this name of this property to something like identifier_is_valid to be clearer what true/false/null mean in that context

If ommited in JSON, we can treat that as "Unknown"

I don’t really understand the point of the OWK record. It seems like it’s just re-hashing the info that already in the WRK and its child WRI records. No new information appears to be included in this record which cannot be deduced from the existing records.

In other words, given this nested chain:

PUB: {
  controlled: true
  ...
  TER: {
     World
  }
}

We don't need to make the distinction between a SPU and an OPU because the controlled: true flag defines it for us.

We also don't need to make the distinction between a SPT and a OPT because we can infer from the structure that the territory belongs to a controlled publisher.

Same thing with WRI vs. SWR and OWR and SWT and OWT.

This lets us minimize the amount of unique records and take advantage of the nested inheritance structure of JSON

Latest EDI spec says yes, cap at 60, but there was some discussion about not requiring a cap and letting societies/recipients truncate if necessary.

https://json-schema.org/understanding-json-schema/reference/string.html

The description for the organization_code property in the XRF record arbitrarily adds and removes valid values from the Transmitter Code lookup table. e.g. it adds the values ISW and ISR and removes the values 000 and 099 from the Transmitter Code table. Should a separate table be created for this organization_code property adding and removing the relevant so that the referenced lookup table is accurate as is

The ORN record seems to only contain information about the WRK itself, nor does it seem possible for there to be multiple ORNs for a given WRK. There does not appear to be a need for nested separate record hanging off of the WRK. We could just “pull up” the relevant ORN properties to the WRK level.

The description for the audio_visual_productions property on the WRK record references the ORN record. If we pull up the ORN’s properties to the WRK level, we should revise this description accordingly

See #41

Given this definition:

The EDI BNF for WRK is:

The square bracket suggests that SPUs and SWRs are not required, enabling a situation where a WRK could be submitted without any writer or pub info which doesn't make a lot of sense

I can't remember, was the decision to remove sequence numbers because they're now effectively irrelevant?

They don't look right, shouldn't be an array, we're defining a single record here, not choreographing the entire CWR JSON file which may contain multiple PWRs in an array

e.g. territory information like SPT/OPT

They are incorrect now

Should be easy to do something like "if the composite type is entered, then the composite component count is required"

But may be difficult to encode "if the composite type is entered, and ASCAP is represented on the work, then the composite component count is required"

to make sure they're implemented correctly.

If they are, do we need to add them to other records which don't have them?