@makxdekkers - pinging you again about this, it would be great to have your review about this

Mostly OK, but there are a number of properties in the dct:relation with the adms:Asset, namely: dcat:downloadURL, dcat:mediaType, dct:conformsTo and dct:description that seem to be properties of the adms:AssetDistribution and not of the adms:Asset.

So I think there should be a dcat:distribution property under the adms:Asset with:
dcat:distribution [ a adms:AssetDistribution ; dcat:downloadURL etc

OK - I've added two distributions of the Ontology - in Turtle and RDF/XML.

See https://rawgit.com/w3c/dxwg/dcat-issue317-simon/dcat/index.html#bag-of-files
and https://github.com/w3c/dxwg/blob/dcat-issue317-simon/dcat/examples/csiro-stratchart.ttl

Thanks @dr-shorthair. Looking more closely at the two sections with links to the images, I see that you describe them with dcat:downloadURL and dcat:mediatype, but both those properies have domain dcat:Distribution so it is being implied that the images are dcat:Distributions. It might be better to describe them without DCAT-specific properties but use the equivalent DCMI terms instead.
Something like:

dct:relation <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg> ;
...

<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg> [
      rdf:type foaf:Document ;
      dct:type <http://purl.org/dc/dcmitype/Image> ;
      dct:format <https://www.iana.org/assignments/media-types/img/jpeg> ;
      dct:description "Coloured image representation of the International Chronostratigraphic Chart" ;
      dct:issued "2017-02-01"^^xsd:date ;
      dct:title "International Chronostratigraphic Chart" ;
    ] ;

Else relax the domain of dcat:downloadURL and dcat:mediatype so use of these properties does not necessarily entail that the resource is a dcat:Distribution ?

I note that this was potentially up for consideration in #126 and #127 which were closed a long time ago.
I suggest re-opening both in conjunction with this discussion.

@dr-shorthair Is this really necessary? You seem to be suggesting we change the domains of two DCAT properties in order to support an example.
Is there anything wrong with my counterproposal to describe the images with 'regular' DCMI terms?

OK, I was just copying the pattern of dcat:distribution down to the dct:relation cases.
But I guess it does not apply to resources that are not in a DCAT catalog (e.g. foaf:Document).
So where would the descriptions of such related resources, which are neither dcat:Resource or dcat:Distribution, be available from?

My goal here was to show how a simple pattern for how some additional information about the related resources could be included in the graph, but now I'm not sure it is possible.

You ask "So where would the descriptions of the related resources that are neither dcat:Dataset or dcat:Distribution be available from?"
This is always an issue: we would like to rely on the owner of 'external' resources to describe their resources with LOD statements. In the case of http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg, you'd hope that stratigraphy.org provide the set of statements that describe the image. Unfortunately, many resources on the Web do not have that kind of information available, but that is how LOD works (or doesn't work in some cases).

What about using schema.org DigitalDocument type, which allows a URL to explicitly state where to get the resource representation; otherwise it appears one must assume that the URI for dct:relation object is resolvable (which ideally would be true, but not necessarily).

<http://stratigraphy.org/ICSchart/ChronostratChart2017-02> [
      rdf:type sdo:DigitalDocument;
      sdo:url  "http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg";
      dct:type <http://purl.org/dc/dcmitype/Image> ;
      dct:format <https://www.iana.org/assignments/media-types/img/jpeg> ;
      dct:description "Coloured image representation of the International Chronostratigraphic Chart" ;
      dct:issued "2017-02-01"^^xsd:date ;
      dct:title "International Chronostratigraphic Chart" ;
    ] ;

@smrgeoinfo That is another way of doing it. However, you're still creating a description for an 'external' resource that you don't own. Doing so creates a risk as you cannot control what the owner does with its resource. For example, stratigraphy.org could tomorrow reissue the image and from that time the dct:issued in the description you have provided will be incorrect.

@makxdekkers I have revised the PR following your suggestion.

See https://rawgit.com/w3c/dxwg/dcat-issue317-simon/dcat/index.html#bag-of-files
and https://github.com/w3c/dxwg/blob/dcat-issue317-simon/dcat/examples/csiro-stratchart.ttl

FWIW I also made a schema.org variant of the same example

https://github.com/w3c/dxwg/blob/dcat-issue317-simon/dcat/examples/csiro-stratchart.schema.ttl

It is almost complete - the only props I couldn't match are dct:conformsTo and dcat:accessService.

There is some discussion about including something like dct:conformsTo in schema.org (see schemaorg/schemaorg#1516) but not yet available AFAIK.

We do have the prefixes dctype and adms defined in the document. Should we use them too in this example?

Also, section D.1 (https://rawgit.com/w3c/dxwg/dcat-issue317-simon/dcat/index.html#bag-of-files for this PR), presents several representations by adding more details to the same example, which is nice. While this is clear by looking at the IDs, etc, it might be useful to spell it out in the presentation.

I've inserted some rdfs:comment to explain the role and type of the different related resources