Re: Question about identifiers

>From discussions on URI Patterns [1] in UK Gov Linked Data WG many months
ago, we concluded that it's best not to include elements in a URI path that
may change over time - which would suggest that encapsulating concepts such
as organisational hierarchy in a URI will be problematic - the URI no
longer fits the pattern as the hierarchy membership changes.

As Ed suggests, one can always mint a new identifier, but it would be best
avoided. This is one of the basic principles of the WWW architecture:
"avoid URI aliases" [2]

FWIW, the guidance of URI patterns in UK [1] suggests patterns like:

http://{sector}.data.gov.uk{/collection*}[/{concept}/{key}]*{#type}
...or... http://{sector}.data.gov.uk{/collection*}{/type}[/{concept}/{key}]*

(note that the inclusion of the `type` element to determine the type of
resource is probably less of an issue now based on earlier discussions in
SDW WG;  information/document resource, e.g. #doc, the thing itself, e.g.
#id, and spatial object, e.g. #so ... or even the associated vocabulary,
e.g. #def)

e.g.
http://environment.data.gov.uk/catchment-planning/so/RiverBasinDistrict/8,
http://environment.data.gov.uk/catchment-planning/so/OperationalCatchment/3468
and
http://environment.data.gov.uk/catchment-planning/so/WaterBody/GB108050008100

The water body is 'within' the catchment which itself is 'within' the river
basin district etc. ... but no attempt is made to declare these
relationships within the URI structure

(for more on this example data, see the Catchment Data Explorer [3])

[1]:
http://ukgovld.github.io/ukgovldwg/recommendations/uri-patterns.html#uri-pattern-guidance

[2]: https://www.w3.org/TR/webarch/#avoid-uri-aliases
[3]: http://environment.data.gov.uk/catchment-planning/

On Fri, 19 Aug 2016 at 11:12 Ed Parsons <eparsons@google.com> wrote:

> So perhaps best practice is to update the resource at the old URI to point
> to the new one ?
>
> Ed
>
>
> On Fri, 19 Aug 2016 at 11:03 Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
>> On 19 August 2016 at 11:11, Linda van den Brink <
>> 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?
>>
>> Greetings,
>> Frans
>>
>>
>>>
>>>
>>> *Van:* Ed Parsons [mailto:eparsons@google.com]
>>> *Verzonden:* vrijdag 19 augustus 2016 11:02
>>> *Aan:* Frans Knibbe; SDW WG (public-sdw-wg@w3.org)
>>> *CC:* Linda van den Brink; Joshua Lieberman (
>>> 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 ?
>>>
>>>
>>>
>>> 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
>>>
>> --
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com @edparsons
>