cwr-json's People
cwr-json's Issues
Should the copyright number be more international
Currently the description is for US only registrations
And enforced to 12 chars which might not work for all countries
Add lookup table $ref to the identifier_validity property in XRF record (that is, if we do not change it to a nullable boolean)
See #48
Look at Slyvain's spreadsheet to get the heirachy structure
It starts with rightsholders and goes down from there. Gone is the concept of SPUs, SWRs etc.
OWK record needs to be added to schema
Add lookup table $ref for text music relationship on the WRK record
Review the WRI schema
Probably shouldn't have an array property. May need some validation and required fields added
Add conditional validation to the grand rights indicator property on the WRK record
Only required for UK societies. Might be difficult to enforce this conditional requirement in the schema itself
Should Manuscript shares be a separate record or can they be merged into the writer record directly?
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
Review the WRT schema
probably should have a recursive array
Add lookup table $ref for the music arrangement property of the WRK record
Should the INS record actually be a separate record?
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
Should the XRF record’s identifier property be artificially capped at 14 characters?
Review existing regex patterns for accuracy
Should we abolish the 14 character limit on submitter work id
Add conditional validation to the music arrangement property of the WRK record
Should grand rights indicator actually be conditional?
required for UK societies, is it actually used though?
Is the NRT record part of the 3.1 spec?
A schema was added to the JSON spec, but I can't find it referenced in the EDI spec
Add lookup table $ref to the identifer_type property in the XRF record
Add regex patterns where appropriate
Need to review/validate the conditional validations
Have not reviewed yet
Add conditional validation for the lyric adaptation property of the WRK record
Are PWRs required?
Someone mentioned situations where a writer might not have a publisher or vice versa as allowable, valid use cases
The XRF record still needs to be added to the json spec
Should there actually be a character cap on opus number and catalogue number
some opus numbers are really really long, more than 25 chars
Add lookup table $ref to language code on the WRK record
The identifier_validity property on the XRF record does not appear to require a lookup table
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
Should we change F "flags" to boolean
If ommited in JSON, we can treat that as "Unknown"
Is the OWK record actually necessary?
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.
Add conditional validation to duration property on the WRK record
If we consolidate SPU and OPU into something more generic like PUB with a controlled bool flag, do we also consolidate SPTs and OPTs into a generic record like TER (territory)
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
Add lookup table $ref for version type property on the WRK record
Should WRK work_title be capped at 60 chars
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.
Revert the duration properties back from string to duration
Are manuscript shares required?
Add lookup table $ref to the organization_code property in the XRF record
The XRF organization_code is incompatible with the Transmitter Code lookup table
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
Add lookup table $ref for excerpt type property on the WRK record
Add lookup table $ref for musical work distribution category for WRK record
Should the ORN record actually be a separate record?
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 ORN's audio_visual_productions property may need to be updated/revised
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
Add lookup table $ref for composite type in the WRK record
The EDI BNF defintions do not seem to be correct for the WRK record (and possibly all other records)
Sequence numbers
I can't remember, was the decision to remove sequence numbers because they're now effectively irrelevant?
In the NRT schema, the publisher name appears to be incorrectly nested under the title_type property
Review the properties in the PWR schema definition
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
Add the dependencies of a publisher to the PUB record
e.g. territory information like SPT/OPT
Need to go back through all records and validate the $refs
They are incorrect now
Add conditional validation to the composite component count property of the WRK record
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"
Add lookup table $ref for the lyric adaptation property of the WRK record
Review the dependantRequired keys
to make sure they're implemented correctly.
If they are, do we need to add them to other records which don't have them?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.