17 | | The main challenge seems to be a clear definition of '''how the metadata records are linked with the (endpoints of the) repositories/search engines'''. |
18 | | A basic solution is that the ResourceRef of the Collection MDRecord points to the endpoint of given search engine, but this seems to simplistic.[[BR]] |
| 20 | == Linking MDRecords and Content Services == |
| 21 | The main challenge seems to be '''how to relate the metadata records with the (endpoints of the) repositories/search engines''', so that it is possible to map from a MD-result to the candidate repositories to search in. |
| 22 | |
| 23 | === Variant 1: Collection's MDRecord points to the Content Service === |
| 24 | |
| 25 | A basic solution is that the ResourceRef of the Collection MDRecord points to the endpoint of given search engine, but this seems to simplistic. |
| 26 | |
| 27 | === Variant 2: Separate MDRecord `Repository`=== |
| 28 | Define a separate CMD-Profile '''Repository''' (see [[RepositoryRegistry#IdeasonimplementationoftheRegistry RepositoryRegistry]], that carries |
| 29 | 1. the URL of the Content Service endpoint |
| 30 | 1. references to the MDRecords (`<ResourceRef>`) of Collections and/or Resources that are searchable via this Service |
| 31 | 1. any further technical information about the service |
| 32 | |
| 33 | It shouldn't carry any information about the content. That should be maintained separately in the MDRecords for the referenced Collections and Resources. |
| 34 | |
| 35 | |
| 36 | === Variant 3: Use Virtual Collection === |
| 37 | MD-Search could be packed as a virtual collection, sending only a reference of it to the content search. |
| 38 | |