W3C home > Mailing lists > Public > public-sdw-wg@w3.org > August 2016

RE: Question about identifiers

From: Linda van den Brink <l.vandenbrink@geonovum.nl>
Date: Fri, 19 Aug 2016 11:50:28 +0000
To: Ed Parsons <eparsons@google.com>, Frans Knibbe <frans.knibbe@geodan.nl>
CC: "SDW WG (public-sdw-wg@w3.org)" <public-sdw-wg@w3.org>, "Joshua Lieberman (jlieberman@tumblingwalls.com)" <jlieberman@tumblingwalls.com>, "Byron Cochrane" <bcochrane@linz.govt.nz>
Message-ID: <13F9BF0BE056DA42BFE5AA6E476CDEFE725FC352@GNMSRV01.gnm.local>
Yes, I think it would be.

Van: Ed Parsons [mailto:eparsons@google.com]
Verzonden: vrijdag 19 augustus 2016 12:10
Aan: Frans Knibbe; Linda van den Brink
CC: SDW WG (public-sdw-wg@w3.org); Joshua Lieberman (jlieberman@tumblingwalls.com); Byron Cochrane
Onderwerp: Re: Question about identifiers

So perhaps best practice is to update the resource at the old URI to point to the new one ?


On Fri, 19 Aug 2016 at 11:03 Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:
On 19 August 2016 at 11:11, Linda van den Brink <l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>> wrote:
Yes…  it is generally easier to make meaningless IDs persistent. But it is nice to have URIs that are human readable. In the Dutch URI strategy we do advise having human-readable parts in the URI scheme, but say that officially these mean nothing i.e. we say it is extremely ill-advised to ascribe any meaning to {concept} *for the machine*. URIs are opaque in a technical sense. Meanwhile, however, they do give hints to human readers.

Then how can you tell humans that they can interpret the URI and tell machines that they should not? Is there a mechanism for doing that?


Van: Ed Parsons [mailto:eparsons@google.com<mailto:eparsons@google.com>]
Verzonden: vrijdag 19 augustus 2016 11:02
Aan: Frans Knibbe; SDW WG (public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>)
CC: Linda van den Brink; Joshua Lieberman (jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>); Byron Cochrane
Onderwerp: Re: Question about identifiers

While I accept that the current view of URI schemes having no explicit meaning, I do see great value in the /{municipality}/{quarter}/{neighbourhood} as a simple way of expressing geographical hierarchy independent of geometry... What's the worst that could happen ?


On Fri, 19 Aug 2016 at 09:30 Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:

A prime requirement of good URI minting is to not put any meaning in the URI, at least no meaning that is somehow intended for consumers. Everything that needs to be said about a resource, like its membership of data collections or its versioning, can be said in the data that is returned when the URI is dereferenced.

URI schemes like /{municipality}/{quarter}/{neighbourhood} could be dangerous, because consumers could inadvertently try to derive meaning from such an URI. The usefulness of such a scheme in URI minting is also doubtful, because administrative structure can change in time. That could complicate the URI minting procedures over time.

I do wonder to what extent common web crawlers try to parse URIs and attach meaning to URI parts.


On 18 August 2016 at 22:55, Byron Cochrane <bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz>> wrote:

I like the guidance under the URI-Strategy under Hierarchical URIs generally, but have some reservations to this intelligent identifiers approach.
For metadata access I think it is a good thing.  Most metadata for an individual features will usually reside at the dataset or collection (better term) level.  This hierarchical approach makes this metadata easy to access.

But this built in intelligence makes the permanence of the URIs more difficult.  For example, administrative boundaries change through mergers and annexations.  A spatial thing that was in one collection is now in another.  The URIs for these things then confuse more than help.  URI redirects are one way to deal with this, but perhaps tracking these relationships through applied ontologies such as skos:broader and skos:narrower is the better practice?

No answers from me here, just questions.


From: Linda van den Brink [l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>]
Sent: Thursday, August 18, 2016 8:28 PM
To: Joshua Lieberman (jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>)
Cc: SDW WG (public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>)
Subject: Question about identifiers

Hi Josh,

Coming back to the telecon yesterday:

<joshlieberman> Should identifiers be part of a system for the features of interest?

joshlieberman: making identifiers part of a system, where the features are part of the system?
... for example corresponding to paths in a taxonomy

Linda: no answer right now, will have to think about it

Were you talking about recommending some system for creating HTTP URI identifiers, i.e. some sort of URI strategy or pattern? Specifically where the features can be organised into some system like a hierarchy, as with administrative regions? There are some examples from Geonovums testbed here
https://github.com/geo4web-testbed/topic3/wiki/URI-Strategy under Hierarchical URIs.

Just trying to understand what you mean… we could add some guidance to the BP about this. I think that would be helpful.


Linda van den Brink
Adviseur Geo-standaarden

a: Barchman Wuytierslaan 10, 3818 LH Amersfoort
p: Postbus 508, 3800 AM Amersfoort
t:  + 31 (0)33 46041 00<tel:%2B%2031%20%280%2933%2046041%2000>
m: + 31 (0)6 1355 57 92<tel:%2B%2031%20%280%296%201355%2057%2092>
e:  l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl><mailto:r.beltman@geonovum.nl<mailto:r.beltman@geonovum.nl>>
i:  www.geonovum.nl<http://www.geonovum.nl><http://www.geonovum.nl/>
tw: @brinkwoman

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@linz.govt.nz<mailto:info@linz.govt.nz>) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.


Ed Parsons FRGS
Geospatial Technologist, Google

Google Voice +44 (0)20 7881 4501<tel:%2B44%20%280%2920%207881%204501>
www.edparsons.com<http://www.edparsons.com/> @edparsons

Ed Parsons FRGS
Geospatial Technologist, Google

Google Voice +44 (0)20 7881 4501<tel:%2B44%20%280%2920%207881%204501>
www.edparsons.com<http://www.edparsons.com/> @edparsons
Received on Friday, 19 August 2016 11:50:58 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:25 UTC