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

On 2014-06-05 0:41, Andrea Perego wrote:
> Very interesting, Frans.
>
> My comments inline.
Thanks for your comments. Mine are inline too.

Regards,
Frans
>
>> [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.

Will doing something like that be allowed? Phil (Archer) pointed out the 
following in a previous thread:
/"3. What we won't allow is for any term to be deleted or any 
substantive change to its semantics. You can, however, deprecate any 
term. "/

Would dropping a domain/range specification count as a substantive 
change to semantics?

I do notice that all vocabulary terms have status 'testing' or 
'unstable', which seems to indicate that some changes can still be 
expected to happen.

> 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.
I wondered the same thing.

I did just notice the treatment of administrative units. In the 
vocabulary, we have locn:adminUnitL1 and locn:adminUnitL2. That is a 
very straightforward way of handling a concpet with multiple levels. If 
this treatment would be applied to location designators, we would have 
locn:locatorDesignatorL1, locn:locatorDesignatorL2, 
locn:locatorDesignatorL3. But that will probably constitute a 
modification of the vocabulary, rather than an extension. And 
modifications are not good for long term stability....


>> 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

In a sense, in my data set each locatorDesignator is associated with a 
type too.  Addresses have locn:designators, but the same values are cast 
using properties from the national data model. Those properties have 
different names and a known order. An example: 
http://lod.geodan.nl/basisreg/bag/nummeraanduiding/id_0363200000181546/mut_1: 
this is an address with two locn:locatorDesignators, "B" and "22". 
Knowing that "B" is also a bag:huisletter and "22" is also a 
bag:huisnummer should make the right order clear. But that is very 
awkward. It would be great if it is possible to get a well formed 
address by just using the location core vocabulary, without having to 
know about national semantics.

Could the INSPIRE code list above be used in publishing Linked Data in 
conjunction with LOCN somehow?

> Cheers,
>
> Andrea


------------------------------------------------------------------------
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
------------------------------------------------------------------------