Allow non-rdf resources as auxiliary resources

[damooo]

As per spec, currently auxiliary resources can be just LDP-RSs.

Auxiliary resources are represented as RDF documents [RDF11-CONCEPTS]. HTTP interactions on auxiliary resources are subject to the requirements as per Reading and Writing Resources.

There are many use cases where NRs to be exposed as auxiliary resource, tightly tied to subject resource's acls/life-cycle.

following are some use-cases, where custom solid implementations may want such auxiliary resources.

1. For a given image resource say <a.png>, may be of very high resolution, a custom solid server can auto-generate a thumbnail auxiliary resource <a.png.thumb.png>.
2. A digital-humanities oriented or any other solid-server may want to provide iiif-image api for every subject image resource, with authz & lifetime tightly linked to subject resource. For a given image <a.png>, a iiif-image api, provides an info resource like <a.png.iiif/info.json>, and dynamic resources with format <a.png.iiif/$region/$size/$rotation/$quality.$format> such as <a.png.iiif/0,0,10,100/256,256/0/grey.jpg>. A solid server can easily implement such api resources as auxiliary resources, with desired properties of auth, lifetype binded to subject image resource. And for an auxiliary resource, iri's slash semantics need not be those of solid resources.
3. One may want to read certain xpath of an xml subject resource, like a section in TEI-document.
4. Any of such derived NR resources, like a pdf-page, a file in an archive, etc. can use this pattern of auxiliary resources. Thus if certain domains require preferential treatment to certain NR types, with support of standard apis for them, this pattern will achieve it with little disturbance, and architectural simplicity, with goodies of solid's authz, crud, etc.

[damooo]

Is there any prior discussion, that resolved to allow only rdf-documents as auxiliary resources? If so can some one help in pointing it out, so that i can be better informed?

[bourgeoa]

You can look in issues select label topic: auxiliary-resources

[kjetilk]

Thanks for the use cases! I think we should look into this when we look into a designing an extensible mechanism for auxiliary resources (#306).

[csarven]

There is probably prior discussion in the LDP WG that you may want to look into. There may have been a minor discussion/comment about it in the Solid repository but nothing overly significant.

The cases seem to call for both RDF and non-RDF auxiliary resources, as well as an API.

The example with the thumbnail doesn't come across meaningful or easily workable to me. How about thumbnails with different sizes or formats?

An auxiliary resource is more like "see also" as opposed to an "attachment".

Discovery is the key part of all of this. The relation.

describedby gives the generic possibility to further describe the subject resource. We are not limited to that. If a new relation is needed to discover a particular kind of resource / with a generally well-defined topic/concept about its intentions, we can introduce that. As it stands, the need to have a non-RDF resource as an auxiliary resource doesn't jump out at me.

[damooo]

Thanks @bourgeoa , @kjetilk , @csarven for replies and insights.

@csarven ,

The example with the thumbnail doesn't come across meaningful or easily workable to me. How about thumbnails with different sizes or formats?

I gave thumbnail example as some simplified use-case which conveys essence, without delving into technicalities much. If there is a iiif-image api, it serves the purpose of thumbnail too. That's also established practice in iiif-viewers, apps like open-sea-dragon, mirador, universal-viewer, etc. But in itself such simple api can be sufficient for some other pragmatic use cases. for example metaphacts' platform uses such simple api, to power it's powerful linked-data-browser.

describedby gives the generic possibility to further describe the subject resource. We are not limited to that. If a new relation is needed to discover a particular kind of resource / with a generally well-defined topic/concept about its intentions, we can introduce that. As it stands, the need to have a non-RDF resource as an auxiliary resource doesn't jump out at me.

Here it is not just about discovery. If it is so, they can be indeed yet another resources, with a relation connecting subject res. The important need is that of to tie acls, and lifetimes of these resources to those of subject resource. And in solid, such possibility only exist with auxiliary resources as of now.

And there seems no justified reason on why auxiliary-resorces have to be rdf-docs while resources can be both RS, and NRS.

[damooo]

@kjetilk , @csarven
Indeed, it is clearly expressed in dimensions issue.
These use-cases primarily depends on dimensions of discovery, binded-acls, binded-lifecycles, and server-management.

[csarven]

I'd suggest to create an issue specifically about "Support IIIF Image API" to investigate how far a Solid server (based on the Solid Protocol) can support the API out of the box, identify the shortcomings or any conflicts. That'd be very useful information.

And there seems no justified reason on why auxiliary-resorces have to be rdf-docs while resources can be both RS, and NRS.

What kind of a "justification" would be adequate? It doesn't exist because there was no significant set of use cases brought forward to date. I've responded to the thumbnail case you've brought forward. It is more like a(n IIIF image) service that can generate descriptions to resources based on requests matching a URI Template. As for any (meta)data about an image (binary) resource, that's currently done / assumed to be through an associated Description Resource (~Image Information).

As for wiring up access controls or other associations or behaviours between the subject (image) resource and the possible manifestations of the resource, that needs to be worked out. But I don't think it quite fits into the auxiliary resource view as it stands.

Solid's auxiliary resources - to date - are for the most part static (and mutable) resources with their own descriptions. An Image Information Resource could potentially link to all possible things that an image service might also provide - although probably impractical.

[csarven]

On a related note, a solid server could be generate Exif data in RDF: https://www.w3.org/2003/12/exif/ and have it available from a resource associated with the image (via describedby or another property).

[damooo]

Issue is not just about iiif.
For example tei-publisher is a tool that take tei-xml file and embedded directives, and outputs htmls of tei-document parts . Those html resources are indeed separate resources, with their own representations, and possibly descriptions. It is required to make them available with same acl of subject tei, and binded to life cycle of subject tei.

Case is not just about read only. There can be writable auxiliary resources which require above dimensions of binding to subject resources.

It is request for generic framework, instead of special case for image resources.

What kind of a "justification" would be adequate? It doesn't exist because there was no significant set of use cases brought forward to date

The spec exercised intentional restriction of RS, hence i thought there was some deliberation for that exercise of restriction.

[damooo]

@csarven ,
If not as auxilliary resources, then can we have something like auxilliary-api? So that, on top of solid-defined base CRUD api, we can interact with given resource, through custom api whose acls and lifecycles are bound to target resource.

Currently even rdf-resources needs special api to access them conviniently. This we are seeing in pagination resources, specifically for rdf-resources. These pagination resources/api, share same dimensions of bounded-acls, and bounded-lifetimes etc. So instead of having special case for target as rdf-resources, and api being that of pagination, it will be more natural, if we can reduce it to fundamentals and allow target being any resource, api being any custom/standard api.

This seems is in-line with thoughts expressed by @RubenVerborgh at Paradigm shift 3: Interfaces become queries, though for all resources. Thus we can have pagination-api over rdf-resources, or overview api over rdf-resources, iiif api over image resources, xquery on xml, tei-publisher api over tei-resources, etc. if a domain requires such support for few resource-types.

[damooo]

Hello @csarven , @kjetilk request you to show torch on how can we achieve following requirements in solid-compilant-way.

1. Just like there are discussions on having shape files as auxiliary resources to validate rdf-sources, in many domains, we may want to have xmls/relax-ng schema as auxiliary resource to validate an xml resource, or a json-schema for validating json resource. Those domains' lingua-franca uses those formats extensively(for narrative docs, etc.), and there is need to maintain wellformedness and consistency. These auxiliary needs can be easily fulfilled with NR-aux-resources(writable resources in these cases), if server choses to support. What else can be recommended way?
2. IIIF have a static profile. Thus we can have a folder of static server-generated-resources for given image, satisifying level1 profile. It will be natural to serve these static resources as auxiliary-server-managed-readonly resources. Thus it enables lifecycle, acl binding to original resource in elegant way. What else can be way forward?
3. Same way, given a TEI+XML ODD file, TEI-Publisher geberates static folder of html files, and pdfs, which can be served as rendered book. Any change to original resource, will trigger live-regeneration. If they can be served as NR-aux resources, above mentioned desired properties can be easily achievable.

Thus there can be many auxiliary needs that can not be fulfilled by RDF resources only. These cases, where we have to bind lifecycles, and acls to original resource, and also serve auxiliary functionality seems not fringe.

The name itself says auxiliary-resources instead of auxilliary-rdf-sources. Some how this restriction feels arbitrary and asymmetric.

[kjetilk]

Thanks a lot, @damooo . I think we take this up in a larger discussion on aux resources, but we're focusing on getting 0.9 done, so I'll just ask that you hang in there until we've done that :-)