Re: Multiple representations of the same resource without content negotiation

Hi Armin:
This is a personal response, not a response from the LDP WG.

As things stand, content negotiation can only be used to negotiate different
encodings of the same resource.  For example, a document in English or in
French,  Or the temperature in Fahrenheit or Celsius.  It cannot be used to,
say, negotiate between a text description and a picture.

My recommendation would be to give distinct URIs to different representations.
For example, if the URI is for a rock then
.../therock/description
.../therock/jpeg

Hope that helps.

All the best, Ashok

On 9/23/2012 7:24 PM, Armin.Haller@csiro.au wrote:
> Dear all,
>
> I am running this by the mailing list to solicit your opinions if this is relevant to the LDP before I post it to the issue list.
>
> In a series of Linked Data projects in CSIRO we have the following requirement on a Linked Data Platform. Consider, for example, a physical feature that can be identified and mapped. Multiple information resources may exist for a single object, may this be one of several machine readable cartographic representations (e.g. different levels of detail), several types of pictures, HTML descriptions or RDF graphs of information about the object. We desire a single URI that represents the "real world thing" as postulated by the Linked Data principles. However, multiple representations of this thing (URI) exist. Such systems are common in the "Data Web" and although highly heterogeneous, represent a significant, and in some cases legislated resource base that can be linked.
> Of course content negotiation can be used to retrieve the different representations of the same object. However, how does the user know what representations do exist about this object? Also, what if the representation is a native API itself? Native APIs and formats are supported by existing clients, so the goal of a LDP here is arguably to broker a client getting access to the resource in the right representation with minimal overhead. As such, the LDP platform could be considered as a URL resolver for an object representation. If we allow this functionality the following issues arise:
>
> ● Do we encode the representation types in a graph about the object (e.g. in a representation/type ontology, a VOID description, etc.)?
> ● Do we require the user to query this graph to determine the different representation about an object or do we offer an API that allows the user to natively query for different representation of the thing other than RDF/JSON/HTML?
> ● If we do, how are CoolURIs resolved to multiple possible representations? Do we use an identifier for the representation type?
> ● Can we use identifiers for the same object from other contexts if they support LD, or are they just alternative representations?
> ● How do we know when a URI acts as a LD identifier or as an information resource?
> ● What is the minimal API needed for handling multiple identifiers and representations across multiple communities?
> ● How do we provide links to native APIs, e.g. MAP APIs, Web Feature Server, etc.?
>
> Looking forward to your opinions!
>
> Best regards,
> Armin
>

Received on Monday, 24 September 2012 18:24:50 UTC