Presentation: seeAlso: Clarification on need for unique URIs for resources.

[rogerhyam]

In the Presentation API in 3.3.1 seeAlso the text says:

"The URI of the document must identify a single representation of the data in a particular format. For example, if the same data exists in JSON and XML, then separate resources should be added for each representation, with distinct id and format properties."

The first sentence implies that the JSON representation of the data must have a different URI to the XML representation of the data.

The second sentence can be read that both should have separate resources which should have unique combinations of id and format. i.e. they can have the same URI but different mime types in the format.

This needs to be clarified because if the first sentence is correct it breaks semantic web best practices with regard to content negotiation in which we have a single HTTP URI which gives a 303 redirect to an appropriate resource based on the Accept header presented by the client. The same URI will therefore need to be used in both seeAlso resources.

This should be possible to support content negotiation and 303 redirection

"seeAlso": [
        {
          "id": "https://data.rbge.org.uk/herb/E00421509",
          "type": "Text",
          "label": { "en": [ "Catalogue page for this specimen." ] },
          "format": " text/html"
        },
       {
          "id": "https://data.rbge.org.uk/herb/E00421509",
          "type": "Dataset",
          "label": { "en": [ "Specimen Description in RDF XML." ] },
          "format": "application/rdf+xml"
        }
]

However this may break applications that assume all seeAlso resources have a unique id.

(I'm posting this straight as an issue rather than discussing on the google group because it is pretty damn techie and will confuse a general audience)

[azaroth42]

This is required because the different representations have different properties. As, in your JSON-LD, the id is the same URI, and the id is the subject of the triples, the data would resolve to:

{
  "id": "https://data.rbge.org.uk/herb/E00421509",
  "type": ["Text", "Dataset"],
  "label": {"en": [ "Catalogue page for this specimen.", "Specimen Description in RDF XML." ]},
  "format": ["text/html", "application/rdf+xml"]
}

Which is not very useful :)

[rogerhyam]

The workaround for this is the publisher to add an #anchor to the URIs to make them unique in this particular context.

I'm uncomfortable about this because it feels a lot like a hack. It is legitimate for a URI to return multiple formats and have multiple roles. We shouldn't therefore be using the URI that provides the data as the ID of a node in the document where we want to give that URI a particular role - if you follow me.

i.e. There is this resource X that provides these services and has this label and is accessed through URI Y.

But I see it is done for services as well so we may as well stick with it. I'll change my recommendations into hacking an anchor on the end of the URI to make it unique.

[azaroth42]

Closing rather than migrate to 4.0. In IIIF we have a design principle that says not to have multiple representations served from a single URI.