Re: Using the core location vocabulary to query national address data

Very interesting, Frans.

My comments inline.

> [snip]
>
> I do seem to have two remaining issues:
>
> 1) Properties like locn:thoroughfare or locn:postcode have domain
> locn:Address. In my case I could not make that happen for locn:thoroughfare,
> because a thoroughfare is modelled as a class
> (http://lod.geodan.nl/vocab/bag#OpenbareRuimte). The name of a thoroughfare
> is a property of this class, not of the class that is equivalent to the
> address class (http://lod.geodan.nl/vocab/bag#Nummeraanduiding).
>
> What do you think: is LOCN too restrictive for these properties? Or could
> and should I try to make some changes to my data model to make thing right?

This issue popped up also in the ISA Core Location pilot:

https://joinup.ec.europa.eu/asset/core_location/document/core-location-pilot-interconnecting-belgian-address-data

I'm cc'ing Stijn Goedertier, who led the ISA team working on the pilot.

The proposed solution was to use specific properties and classes,
based on the INSPIRE data specification on Addresses (v3.01), but
re-using as much as possible the properties defined in LOCN (e.g.,
locn:geographicName, locn:locatorDesignator, locn:postCode,
locn:postName), irrespective of their domain and range specification.
Actually, one of the results of the pilot was to consider dropping the
domain/range specification for properties locn:geographicName,
locn:locatorDesignator and locn:locatorName.

The LOCN pilot provides already some ideas about complementing the
LOCN vocabulary with specific extensions, and on possible re-use
criteria of terms defined in the Core LOCN vocabulary.

Frans, I wonder whether the issues you're pointing out might be
addressed by a specific extension of the LOCN vocabulary.

> 2) The order of location designators. This issue was already discussed in a
> previous thread, but perhaps it helps to have some real data to play around
> with. The second query above returns addresses with multiple
> locatorDesignators. For example, "12" and "B". The order is important, 12B
> is the right order. But how can an agent that only knows about LOCN know the
> right order? Is a change to LOCN needed ? Or are there other ways to solve
> this problem?

The approach adopted in INSPIRE is to associate each component with a
type, denoting in general what a locator designator identifies - see:

http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/

Some of this types implicitly denote the order of the specific
component in the locator designator (not at a formal level, anyway) -
see, e.g.:
- address number
- address number 2nd extension
- address number extension
- building identifier
- building identifier prefix
- corner address 1st identifier
- corner address 2nd identifier

Cheers,

Andrea

Received on Wednesday, 4 June 2014 22:42:34 UTC