- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Fri, 19 Aug 2016 10:28:58 +0200
- To: "SDW WG (public-sdw-wg@w3.org)" <public-sdw-wg@w3.org>
- Cc: Linda van den Brink <l.vandenbrink@geonovum.nl>, "Joshua Lieberman (jlieberman@tumblingwalls.com)" <jlieberman@tumblingwalls.com>, Byron Cochrane <bcochrane@linz.govt.nz>
- Message-ID: <CAFVDz43izkk1VpWjWq04LC77HK2_oZUf0Ur3A2SObZu_AJUHhA@mail.gmail.com>
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. > >
Received on Friday, 19 August 2016 08:29:29 UTC