Re: Packaging on the Web

Thanks a lot for your response, Jeni.

Apologies for not formulating my 303 question more accurately. It was
really about how to request a package that follows:
- the HTML path
- the RDF path
of sections 4.2 and 4.3 of http://www.w3.org/TR/cooluris/ , i.e. a
package that contains text/html or an RDF serialization, respectively.

Would you propose to handle that also by means of sub-types?

Greetings

Herbert



On Sun, Feb 2, 2014 at 2:09 PM, Jeni Tennison <jeni@jenitennison.com> wrote:
> Hi Herbert,
>
>> (a) With different serializations of the root RDF document being
>> available, how does a client request a preferred one? From the
>> "Accept: multipart/package,text/json;q=0.9" example you provide, it
>> seems the proposed approach does not provide that functionality.
>> - Is my reading correct?
>> - Could different representations of the root RDF document be included
>> in the same package?
>
> There's no 'root document' in the proposed multipart/package type. But you could invent a subtype like multipart/ore+package in which the first of the documents was the 'root document'. Then you could define a parameter for that subtype for the type of the 'root document', which clients could then use in the Accept header:
>
>   Accept: multipart/ore+package;root=text/turtle
>
> or you could define other mechanisms for identifying the alternate representations of the root RDF document, through the content of the root RDF document itself.
>
>> (b) More generally, how does the proposed approach work with the 303
>> style approaches of Cool URIs for the Semantic Web [4], i.e. how to
>> express interest in a package with an RDF root document, an HTML root
>> document?
>
> Do you mean in order to indicate that particular URLs will result in a 303 response redirecting to another document? I think that's beyond scope for the types of packages that we've been thinking about: it's handled better with some of the archiving formats that are listed in the 'Other Packaging Formats'. But I think you could use essentially an empty document within the package, with a Link header with rel=describedby to record the relationship.
>
>> (c) The constraint to limit `Content-Location`s for the files in a
>> package to the domain that the package is hosted on is understandable.
>> Still, for example in the Research Object case, there can be a need to
>> include a specific representation of a "remote" aggregated resource,
>> e.g. a specific version of an evolving resource that was used to
>> obtain a research result. In this case, does the constraint imply that
>> the author of the aggregation needs to:
>> - Collect that specific representation (this would have to be
>> done whichever way)
>> - Host that specific representation at a URI under its control
>> - Include that specific representation in the package with that
>> URI as Content-Location
>> - Provide a link to the remote URI in the header fields for that
>> specific representation with an appropriate relation type,
>> e.g. Memento's "original"
>
> Yes, I think that would be a way to do it, or you could set up a proxy to handle such requests. You could record the original responses as message/http documents to preserve all the necessary information (including headers) from the origin. Even then, a client consuming the package would have to trust that you hadn't manipulated the document in any way.
>
> Cheers,
>
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com/
>
>



-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

==

Received on Monday, 3 February 2014 16:20:04 UTC