Re: Packaging on the Web

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/

Received on Sunday, 2 February 2014 21:09:56 UTC