Re: Packaging on the Web

Herbert,

You mean, how would a client that had received a package perform content negotiation? Without a server in play, you can’t do proactive (server-driven) content negotiation. I think a package would have to provide enough information to enable the client to select the appropriate document itself, aka reactive content negotiation [1]. In other words, the package would need to include enough information about the types of the documents held in the package to choose which to use.

An alternative would be to have multiple documents with a given Content-Location within the package, but with different Content-Types.

Jeni

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-3.4.2
--  
Jeni Tennison
http://www.jenitennison.com/

------------------------------------------------------
From: Herbert van de Sompel hvdsomp@gmail.com
Reply: Herbert van de Sompel hvdsomp@gmail.com
Date: 3 February 2014 at 16:20:03
To: Jeni Tennison jeni@jenitennison.com
Subject:  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  
> 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 Tuesday, 4 February 2014 08:30:40 UTC