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
My assumption is that the olo:Slot objects are added by Acropolis and are not part of the original data source that the data came from. If this is the case, the olo:Slot objects should either always be present or always absent.
If the output varies unpredictably, it could make it difficult for a client to figure out how to process the RDF for a proxy URI.
The text was updated successfully, but these errors were encountered:
Interpretation of returned RDF must always depend upon the properties associated with the resource being requested. olo:Slot, as with any other property, are present when there is data to include and not when there isn't.
See bbcarchdev/patchwork#3 for the approach we're taking to make this a little clearer, although there will still be cases where the sub-graphs do not include any olo:Slot properties because there are no related items of the specified type.
The RDF for a proxy URI sometimes contains olo:Slot objects and the expected search results format, and sometimes doesn't.
Compare:
http://acropolis.org.uk/9d6f86627b4c46eca3dda409d611c27e.ttl (no olo:Slot resources)
http://acropolis.org.uk/6ec96f5bd2c64232a17d132334f1da75.ttl (olo:Slot resources)
My assumption is that the olo:Slot objects are added by Acropolis and are not part of the original data source that the data came from. If this is the case, the olo:Slot objects should either always be present or always absent.
If the output varies unpredictably, it could make it difficult for a client to figure out how to process the RDF for a proxy URI.
The text was updated successfully, but these errors were encountered: