Using the core location vocabulary to query national address data

Hello,

Since my message 
<http://lists.w3.org/Archives/Public/public-locadd/2014May/0001.html> 
about having published the Dutch national database of buildings and 
addresses I have made some progress. I did get inference to work in 
Virtuoso, without a need for data consumers to know about the inference 
rules. This makes it possible to query the data using only terms from 
the Core Location Vocabulary. An example request for all cities and 
villages (all examples can be run on http://lod.geodan.nl/sparql):

prefix locn: <http://www.w3.org/ns/locn#>
select *
from <http://lod.geodan.nl/basisreg/bag/woonplaats/>
where {
     ?location a dcterms:Location .
     ?location locn:geographicName ?name
}

Note that the only name space defined in the query is locn, the prefix 
for the national vocabulary (http://lod.geodan.nl/vocab/bag) is absent. 
I think this is a very significant result, because it demonstrates that 
datasets can be published according to national data models and still be 
usable internationally, using simple global vocabularies like Core 
Location. Of course it is  something that INSPIRE is aimed at too: 
internationally interoperable data, using common semantics. The 
particular case of addresses is exemplary because the address 
specifications of INSPIRE and LOCN are very similar.

Here is another example that request the addresses with a particular 
postal code:

prefix locn: <http://www.w3.org/ns/locn#>
select *
from <http://lod.geodan.nl/basisreg/bag/nummeraanduiding/>
where {
             ?address a locn:Address .
             ?address locn:postCode "1021GL"^^xsd:string.
             ?address locn:locatorDesignator ?locatorDesignator .
}

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?

2) The order of location designators. This issue was already discussed 
in a previous thread 
<http://lists.w3.org/Archives/Public/public-locadd/2014Jan/0151.html>, 
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?

Regards,
Frans

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