Re: Question about identifiers

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