You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The application/sparql-query shouldn't be used as this is the request content type. What it intended (and expected) is the content type of the response. The default content type (if no accept header n request is given) is not defined.
I think we must apply the same logic to the "Content-negotiated RDF", so stick with the default (no accept header in request) content-type of the output.
I regards to the OAI-PMH endpoint, the (The Open Archives Initiative Protocol for Metadata Harvesting)[http://www.openarchives.org/OAI/openarchivesprotocol.html#XMLResponse] specification says:
All responses to OAI-PMH requests must be well-formed XML instance documents.
An OAI-PMH endpoint could provide XML data in one or more MetadataFormats, but this can be discovered by using verb=ListMetadataFormats
In the case of compressed files, which contain one of more files of only one type, to use the MIME type of the contents, rather than application/zip or application/gzip.
How can we make the type of distribution more explicit? A distribution currently looks like:
The type is determined based on
schema:encodingFormat
. We may distinguish:encodingFormat
application/sparql-query
text/turtle
,application/ld+json
etc.text/csv
etc.contentUrl
providing multiple MIME types?application/xml
?application/zip
but that underdetermines the type of file contained in the archive.The text was updated successfully, but these errors were encountered: