| 103 | Although the original idea was to "serialize" all such metadata-fields in a `<f key="{field-name}">`-element, I now prefer reusing existing namespaces. |
| 104 | |
| 105 | `<dc:title>` seems preferable to `<f key="dc:title">`, right? |
| 106 | |
| 107 | However this nested approach seems not directly compatible with the established SRU-based systems, that rather work on flat fields. |
| 108 | And while this can be overcome by providing converter XSL-stylesheets, the information we need seems expressable in a flat structure as well, that makes the more complex (nested) approach questionable: |
| 109 | |
| 110 | {{{ |
| 111 | <sru:recordData> |
| 112 | <ccs:ResourcePID>{PID of the resource}</ccs:ResourcePID> |
| 113 | <ccs:ResourceFragmentPID>{identifier of the resource-fragment (relative to Resource-PID?)}</ccs:ResourcePID> |
| 114 | <ccs:CMDPID>{PID of the CMD-record}</ccs:CMDPID> /* optional */ |
| 115 | |
| 116 | <dc:title>{title of the resource}</dc:title> |
| 117 | /* basically any metadata-fields as is standard in SRU-world */ |
| 118 | ... |
| 119 | |
| 120 | <ccs:DataView type="kwic">Some text with <kw>keyword</kw> highlighted</ccs:DataView> |
| 121 | <ccs:DataView type="text/xml"><meertens:any/> |
| 122 | </ccs:DataView> |
| 123 | <ccs:DataView type="image/jpeg" href="{optional link to the data}" ></ccs:DataView> |
| 124 | </sru:recordData> |
| 125 | }}} |
| 126 | |