753 system details access to computer files

[CECSpecialistI]

https://github.com/uwlib-cams/MARC2RDA/blob/main/Working%20Documents/7XX.csv

[cspayne]

753 relates to #439 - revisit $2. It maps to "has equipment or system requirement", which can only be recorded as an unstructured description. However, in MARC the values of subfields a, b, and c may come from a VES. Can this be indicated using rdf:datatype, like in the decision for 3XX and in X30/65X with indicator 2?

[GordonDunsire]

@cspayne (and others): In general, an RDA unstructured description is similar to a note or a transcription from a manifestation (including the one being described). Transcription is typically associated with the manifestation statement elements in which the manifestation (being described) describes itself. So for the transform, an unstructured description is a note.

I think we have already agreed on the general treatment of notes: the 'content' subfields in order of appearance with embedded or added punctuation, preceded by an appropriate boilerplate phrase based on the field and subfield semantics.

Example from MARC 21 Bibliographic 753:

753 ##$aIBM PC$bPascal$cDOS 1.1 =>

[rdamd:P30162](http://rdaregistry.info/Elements/m/datatype/P30162) 'IBM PC, Pascal, DOS 1.1.' . // simple, with added punctuation and no internal labels [rdamd:P30162](http://rdaregistry.info/Elements/m/datatype/P30162) 'Make and model of machine: IBM PC. Programming language: Pascal. Operating system: DOS 1.1.' . // longer, with added punctuation and boilerplate internal labels The only way of processing the VES information, other than parking it as data provenance, is to mint a skos:Concept. 753 ##$aSony PlayStation 4$0(uri)http://gamemetadata.org/uri/platform/1071$2gcipplatform => [rdam:P30162](http://rdaregistry.info/Elements/m/P30162) . skos:prefLabel 'Sony PlayStation 4' . skos:inScheme [http://id.loc.gov/vocabulary/subjectSchemes/gcipplatform](http://id.loc.gov/vocabulary/subjectSchemes/gcipplatform) . // same list of schemes as 6XX. The subfield $0 values are affected by the PCC guidance on $0 and $1, because this is a VES. **If we can check actual usage**, we could **confirm that all the values come from the GameCip project**, and allow the transform to interpret '(uri) ...' as subfield $1 '...'. But there is a problem: The value given in the MARC 21 example, [http://gamemetadata.org/uri/platform/1071](http://gamemetadata.org/uri/platform/1071), does not de-reference and throws a 404 error. The correct URI for the concept is [https://gamemetadata.soe.ucsc.edu/platform/1071](https://gamemetadata.soe.ucsc.edu/platform/1071). Again, if this is a systematic error, the transform might fix it? It may be safer to mint a local URI, as above plus skos:notation '1071' . then map the transform URI to the active URI as a subsequent process. I think that, irrespective of the presence of VES data, the transform should output a note-type value.