W3C home > Mailing lists > Public > public-ldp-wg@w3.org > September 2012

Re: Multiple representations of the same resource without content negotiation

From: Ashok Malhotra <ashok.malhotra@oracle.com>
Date: Mon, 24 Sep 2012 11:24:12 -0700
Message-ID: <5060A54C.6030601@oracle.com>
To: Armin.Haller@csiro.au
CC: public-ldp-wg@w3.org
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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:31 UTC