Add metadata formats about search-api HOT 6 CLOSED

It would rely on the metadata formats having MIME types and I don't know if that is the case.

That is indeed a problem. As we are speaking about emerging community specific metadata standards, I guess, it is a safe assumption that most of them do not have a registered media type.

The other option that I mentioned would be to append a query parameter to the URL such as /datasets/12345?format=application/vnd.datacite.datacite+xml.

My original suggestion in the meeting was GET /<item>/<id>/metadata/<name>. Now you omitted the /metadata/ part, was that by intention? E.g. do you suggest to melt the call for querying the item and the call for querying the metadata on that item into one single call?

Concerning transforming the <name> part in the request into a format parameter: that would be an option. I'd still suggest to use names of metdata standards advertised by the server instead of mime types as values. We may even combine both approaches by making the format parameter optional and cascade as follows:

1. if the format parameter is provided in the call, use that value to select the metadata standard. Either reply with the metadata or send a 404 status if metadata by that name is not available for that object.

2. if the format parameter is not provided, try content negotiating and return metadata matching a media type provided in the Accept header of the request, if any.

3. if no specific media type in the Accept header matches any available metadata standard, but the Accept header contains a */* fallback entry or if the request does not contain an Accept header, return metadata using some default minimal standard.

4. if content negotiating fails, send a 406 status.

Note however the difference that content negotiating would still be based on media type, while the format parameter would be based on custom, server defined names.

from search-api.

If we follow the OAI-PMH route, there is a required argument to the GetRecord verb which specifies the metadata type

Sure, but we are not going to implement OAI-PMH in that API. It was merely an inspiration on how to design an API providing diverse metadata standards for one single object.

from search-api.

For each object type , define the API calls:
GET / to query a list of object ids for that type. The call should get an optional parameter query to search for a subset. The query format is tbd.
GET // to query one particular object with its relations and attributes.
GET ///metadataformats to query the names of metadata standards supported for that object.
GET ///metadata/ to query the metadata for that object in the given metadata standard.

from search-api.

Could/should this functionality be implemented in the HTTP request as an 'Accept' Header? The client lists the preferred formats in the header of the request. I'm thinking of server-driven content negotiation as described here though I imagine there may be other schemes. I think this is what Datacite implements. It would rely on the metadata formats having MIME types and I don't know if that is the case.

The other option that I mentioned would be to append a query parameter to the URL such as /datasets/12345?format=application/vnd.datacite.datacite+xml.

@RKrahl @louise-davies and @agbeltran may be interested in this.

from search-api.

If we follow the OAI-PMH route, there is a required argument to the GetRecord verb which specifies the metadata type
http://www.openarchives.org/OAI/openarchivesprotocol.html#GetRecord

For the MIME types, we would have a few different types, such as Dublin Core, Datacite, and the PaN format, so these would need to be declared.

from search-api.

This has been suspended - see minutes of Joint Expands/PaNOSC meeting

from search-api.