Browser access to schemas

[PeterParslow]

Relates to #8

The previous request to be able to browse the hierarchy has not been , i.e. use a web browser to dereference URIs built on the expected pattern, in the way I can at https://standards.iso.org.

For example, I can't GET https://schemas.isotc211.org/schemas/19135/-2 in the way that I can GET https://standards.iso.org/iso/19135/-2/; I have to browse from the root or from https://schemas.isotc211.org/schemas/19135.

I understand this may be due to using existing GitHub functionality, but it does mean that in moving from standards.iso.org to schemas.isotc211.org we will lose some useful functionality.

PS. the 'down arrows' in the left pane turn the pointer into a finger, but do not respond to mouse-click. This is odd HTML behaviour, but only really a problem with a lot of content, like https://schemas.isotc211.org/schemas/19115/

[ronaldtse]

@PeterParslow I see, you would like to still see the browser at: https://schemas.isotc211.org/schemas/19135/-2 . Correct?

Basically like a file browser, viewable at every directory.

[PeterParslow]

That's correct.

[PeterParslow]

Listening to GOM report, I browsed that too. I think it's even more important that ontology URLs like https://def.isotc211.org/iso19103/2005/Names#GenericName are dereferencable.

When I've presented the TC211 ontology in other standards groups (smart cities), one of the reasons that they give to not use them is that they "don't work" i.e. they can't use the URIs to find anything out. @BrodeurJS

[ronaldtse]

@PeterParslow we will be updating the site to allow dereferencing to directories.

However, what do you expect this link to "de-reference" to? https://def.isotc211.org/iso19103/2005/Names#GenericName

The "real" URL is https://def.isotc211.org/iso19103/2005/Names.rdf, which contains this:

  <owl:Class rdf:about="http://def.isotc211.org/iso19103/2005/Names#GenericName">
    <rdfs:label>GenericName</rdfs:label>
    <skos:definition>Generic Name is the abstract class ...
...

This URL contains:

• Names which is an invalid path
• #GenericName which is a fragment in the view of an URL that is application specific and depends on the specific MIME-type of the deferenced Names file.

Not trying to be hard here but would like to know what kind of expectations we're talking about.

[PeterParslow]

Question for @BrodeurJS - this URL pattern is common throughout the ontologies.