Project

General

Profile

feature request #9067

[DISCUSS] Allow media to support external links not being files

Added by Andreas Müller 6 months ago. Updated 5 months ago.

Status:
In Progress
Priority:
New
Category:
cdm
Target version:
Start date:
06/12/2020
Due date:
% Done:

10%

Severity:
normal

Description

The current handling of media expects that links stored in Media(RepresentationPart) are media files or can be opened in Universal Viewer.

Often links to Media can only be stored as links to Websites (e.g. html). Websites can not be displayed in Universal Viewer usually (correct?).

If this is the case we need to decide how we want to store such data.

Possible solutions are:

  1. keep everything as it is, the link will be stored in MediaRepresentationPart and MimeType will be set to "HTML" or "unknown" (TODO check correct MIME types), an application needs to decide what to do if we have this MIME type;
    • Pro: nothing to change in model,
    • Con: we have to change the handling for unknown MIME type, currently it is handled as xxx
  2. Use Media.links to store URLs which are not files
    • Pro: nothing to change in model
    • Con: not intuitive, unexpected usage of IdentifiableEntity.links
  3. Add Media.link of class ExternalLink to distinguish file based representations from Websites
    • Pro: it is possible to distinguis from the datastructure if Media should be represented as link or as Image/Movie/Sound
    • Con: new field, semantic overlap with MIME type, need to disallow to fill both fields "links" and "representations"
  4. Same as 3. but having a common base class MediaBase and 2 subclasses Media and LinkedMedia
    • Pro: possible to distinguish from class what reprentation is required; easy to develop specialised TaxEditor UIs; further attributes can be removed from LinkedMedia; MediaKey and PhylogeneticKey could be handled as spearate subclasses of MediaBase, currently it is a subclass of Media
    • Con: new field; semantic overlap with MIME type; switching from one type to the other is bit more difficult; need to adapt existing code to use Media or MediaBase depending on context

Associated revisions

Revision 56a54a09 (diff)
Added by Andreas Müller 6 months ago

ref #9067 preliminary added link attribute to Media to support solutions 3 and 4 if required

History

#1 Updated by Andreas Müller 6 months ago

  • % Done changed from 0 to 10

I preliminary added an attribute link (ExternalLink) to Media class to be able to immediately support solutions 3 or 4 if we will decide for them

#2 Updated by Andreas Müller 6 months ago

  • Status changed from New to In Progress

#3 Updated by Andreas Kohlbecker 5 months ago

I actually see no benefit of the "solutions" 2 - 4 over 1.

Adding additional fields for external links is nothing else than adding a representation with the mimetype text/html. This new idea only gives users two options for adding links which opens a new source of erroneous usage of the data model. We will need to check the content type anyway in order to prevent users from adding links to "image files" as external link. I don't see that we would win anything by this model change but a more complex model.

Considering these options we should not think of links to image files and other links as this is missleading. In terms of ULRs it is only possible to distinguish between files and non files by the protocol part of the URL: file:/// vs. http://. A http url which ends to with something like .../Uh76Z.jpeg strongly suggests that you will get an jpeg image. Another url .../Uh76Z.do, .../Uh76Z may also deliver an image. There is no way to be sure except 1) trusting the server and doing an HTTP GET or HEAD request and read the Content-Type header or 2.) as last resort to download the response object and examine it.

#4 Updated by Andreas Müller 5 months ago

WGB:

als Diskussionsbeitrag der Hinweis, dass wir in der Darstellung im Portal grundsätzlich die Unterscheidung einer Darstellung als Link (URL-Text) und als Zugriff (Bild oder andere Media-Darstellung) haben, und dass das die Form der Darstellung eine editorische Entscheidung für die betreffende Instanz ist. Bei der Druckausgabe handelt es sich bislang ausschließlich um die Ausgabe von Links als Text. In jedem Fall unterscheiden sich diese Links von den automatisch gesetzten (im Block im Portal) dadurch, dass sie von jemandem revidiert wurden, also Teil des taxonomischen Treatments sind.
Bei den Links gibt’s dann noch die Unterscheidung zwischen den auf beliebige Websites und den (hoffentlich) permanent aufgelösten, auch den, die hinter permanenten IDs wie den derzeit verwendeten DOI, CETAF-IDs, IPNI, Tropicos, BHL, JStor Plants stehen. Des weiteren können die definierten Links natürlich noch nach Inhalt klassifiziert werden, also Specimen IDs (heute: CETAF, Tropicos, US-National Herbarium etc.), digitales Druckwerk (BHL, Madrid, Gallica, ....), Name (Tropicos, IPNI).

#5 Updated by Andreas Müller 5 months ago

  • Target version changed from CDM UML 5.15 to CDM UML 5.18

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)