Getting data with no content-type from a ResourceStore

[joachimvh]

How the SimpleResourceStore currently works is to look at the type value of the input RepresentationPreferences to know what kind of representation to return (this corresponds to the incoming Accept header). This is not possible if for some reason we would need a javascript object as representation (e.g., a stream of Quads), since those have no corresponding mediatype. Currently the SimpleResourceStore returns a stream of Quads if the type preference is missing, but this does make some assumptions and might become a problem for non-quad data, or if we have multiple javascript object types.

[RubenVerborgh]

Currently the SimpleResourceStore returns a stream of Quads if the type preference is missing

On the one hand, this is acceptable behavior; but ResponseWriters should reject streams of non-strings if they do not support them. There could be a quad-based response writer.

But on the other hand, even with a type preference, I don't think it's this particular SimpleResourceStore's job to convert representations. Given that you are implementing SimpleResourceStore with an internal Quad buffer, the knowledge of how to convert quads to text should not be re-encoded across such similar stores (let's say, HdtStore). We rather want the decorator pattern for this, with RepresentationConvertingStore.

So note that both are possible; the store (possibly RepresentationConvertingStore) could convert to an RDF format, or ResponseWriter could. However, given that some stores will directly output in RDF formats (SparqlEndpointStore etc.). we might want to keep that functionality in a store.

a problem for non-quad data

Non-quad data likely has an inherent media type, such as image, or worst case, octets.

Currently the SimpleResourceStore returns a stream of Quads if the type preference is missing

So in conclusion, I think it should always do that, otherwise we re-encoded the serialization logic multiple times. A store should only cater to preferences if it is really easy for them. Let's say for instance a SPARQL endpoint, where it has to ask the backend for some serialization anyway, so it might as well ask for the right one. Or if reading from disk, and the disk happens to have the right format, don't re-serialize. But if conversion is needed; don't bother, someone else should do that.

[joachimvh]

So in conclusion, I think it should always do that, otherwise we re-encoded the serialization logic multiple times. A store should only cater to preferences if it is really easy for them. Let's say for instance a SPARQL endpoint, where it has to ask the backend for some serialization anyway, so it might as well ask for the right one. Or if reading from disk, and the disk happens to have the right format, don't re-serialize. But if conversion is needed; don't bother, someone else should do that.

So for example, an AclAuthorizer constructor would take as parameter a QuadConvertingStore since it needs Quads to query the acl files (and we just assume for a second that there is not a separate query class). And this QuadConvertingStore would have been made with for example the SimpleResourceStore as constructor parameter (or whatever resource store is being used internally), while other components would use that resource store directly as parameter instead of the converting store?

[RubenVerborgh]

So for example, an AclAuthorizer constructor would take as parameter a QuadConvertingStore

Yes; exactly (to everything you wrote).

Although very specifically, I think that we could just have one RepresentationConvertingStore with multiple Convertors inside, i.e., QuadConvertingStore = RepresentationConvertingStore with a TextToQuadParser (or an NQuadParser, JsonLdParser, etc.).

[joachimvh]

How would the QuadConvertingStore know that the SimpleResourceStore can directly return Quads, or any type for that matter? Should ResourceStores perhaps have a function returning which types they actually support?

[RubenVerborgh]

How would the QuadConvertingStore know that the SimpleResourceStore can directly return Quads, or any type for that matter?

At the moment, I think that QuadConvertingStore would just pass the RepresentationPreferences to the SimpleResourceStore, which would try (only simple efforts!) to satisfy them. If not, it just gives its best-effort representation back (which would be quads).

Should ResourceStores perhaps have a function returning which types they actually support?

That could be different per resource though.

[joachimvh]

Related since this is probably also going to be the responsibility of the RepresentationConvertingStore, how to know which content types a ResourceStore supports when writing data to it? This can be done entirely static by choosing the correct classes using dependency injection, since we know what the bodyparser is going to return (quad or binary data streams), and we know what the Resource store is going to accept (text/turtle in the case of a file store, probably quads for a sparql store). On the other hand, it might be nice to have a more flexible solution, so the converting store can determine to what type it should convert before calling the the set/add functions. Having something like that might also help when looking into implementing the Accept-Post header as mentioned in #45 .

[RubenVerborgh]

Related since this is probably also going to be the responsibility of the RepresentationConvertingStore, how to know which content types a ResourceStore supports when writing data to it?

I hadn't designed anything for that yet.

It might be possible for a ResourceStore to implement an additional interface with a getter that indicates accepted formats.
Would not make that part of the main ResourceStore interface though.

since we know what the bodyparser is going to return (quad or binary data streams)

So normally the body parser wouldn't be invoked for a PUT (unless validation happens), but would be for a PATCH.