- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Fri, 19 Aug 2016 12:01:35 +0200
- To: Ed Parsons <eparsons@google.com>
- Cc: "SDW WG (public-sdw-wg@w3.org)" <public-sdw-wg@w3.org>, Linda van den Brink <l.vandenbrink@geonovum.nl>, "Joshua Lieberman (jlieberman@tumblingwalls.com)" <jlieberman@tumblingwalls.com>, Byron Cochrane <bcochrane@linz.govt.nz>
- Message-ID: <CAFVDz43J6j2ZbHUgK7eEZDyOTWwoNWk6emuOC785Po1OgnBjBQ@mail.gmail.com>
Hi Ed, I am not sure this the worst, bit this is something that could happen... Building 1234 is located in municipality X, in quarter Y and neighbourhood Z. Data describing the building are published with URI http://www.example.org/x/y/z/1234 Then there is an administrative reorganisation - municipality bounderies are shifted and the building is now part of municipality W. The URI does not change, and it needs to keep existing because we don't want link rot. Effects are: - The URI no longer follows the scheme /{municipality}/{quarter}/{neighbourhood}. - Suppose there is a need to publish data about the door of the building as a web resource. Should the URI of the door start with http://www.example.org/x/y/z/1234? In that case the URI minting procedure should be smart (i.e. complicated), because it needs to know about the history of the parent resource. Or should the URI start with http://www.example.org/w/y/z/1234? In that case the URI of the building does not lead to the URI of the door by following the URI path. In both cases, a data consumer can not predict which solution the publisher will prefer. - Consumers could wrongly infer that building 1234 is part of municipality X and even publish new data based on that assumption. OK, when pushed to the worse that could happen...bombing a wrong location comes to mind. The military in the Middle East seem to be quite careless nowadays. Regards, Frans On 19 August 2016 at 11:01, Ed Parsons <eparsons@google.com> wrote: > 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 ? > > Ed > > > On Fri, 19 Aug 2016 at 09:30 Frans Knibbe <frans.knibbe@geodan.nl> wrote: > >> Hi, >> >> 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. >> >> Regards, >> Frans >> >> >> >> On 18 August 2016 at 22:55, Byron Cochrane <bcochrane@linz.govt.nz> >> wrote: >> >>> Hi, >>> >>> 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. >>> >>> Cheers, >>> Byron >>> >>> ________________________________________ >>> From: Linda van den Brink [l.vandenbrink@geonovum.nl] >>> Sent: Thursday, August 18, 2016 8:28 PM >>> To: Joshua Lieberman (jlieberman@tumblingwalls.com) >>> Cc: SDW WG (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 >>> >>> ______________________________________ >>> Geonovum >>> 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 >>> m: + 31 (0)6 1355 57 92 >>> e: l.vandenbrink@geonovum.nl<mailto:r.beltman@geonovum.nl> >>> i: 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) 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 > www.edparsons.com @edparsons >
Received on Friday, 19 August 2016 10:02:09 UTC