Re: Trying to use locn:locatorDesignator

Frans, Bart,

Actually, in INSPIRE, the use of code list values to denote the type of
"locator designator" is foreseen only in feature type "Address", and not in
data type "Address Representation", which is the one used as a basis for
class locn:Address, where you can just have a set of ordered
locatorDesignator's.

So, using feature type "Address", your example might be expressed in RDF
like this:

<http://location.data.ex/so/ad/Address/12345>
  a ad:Address ;
  ad:locator [
    a ad:AddressLocator ;
    ad:designator [
      a ad:LocatorDesignator ;
      ad:designator "11B"^^xsd:string ;
      dct:type <
http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressIdentifierGeneral
>
    ] ;
    ad:designator [
      a ad:LocatorDesignator ;
      ad:designator "11"^^xsd:string ;
      dct:type <
http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumber
>
    ] ;
    ad:designator [
      a ad:LocatorDesignator ;
      ad:designator "B"^^xsd:string ;
      dct:type <
http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumberExtension
>
    ] ;
    ad:level <
http://inspire.ec.europa.eu/codelist/LocatorLevelValue/siteLevel>
  ] .

In the lines above, the ad: prefix denotes a fictitious RDF vocabulary for
INSPIRE "addresses" (see the corresponding UML diagram at [1]). Besides the
fact that such voc does not (yet) exist, I'm afraid this is far more
complex than needed for your use case. Note that, to avoid further
complexity, in the lines above there's nothing about the "order" foreseen
in INSPIRE for the "locator designator", as done by Stasinos in his example.

I wonder whether what you need is just a way to order the different parts
of a locator designator, or rather to express the semantics of such
components.

In the latter case, a possible solution is to define sub-properties of
locn:locatorDesignator, e.g., corresponding to (some of) the values in code
list  LocatorDesignatorTypeValue [2]. An alternative is to use the code
list to denote the locator designator type - e.g., partially re-using
Stasinos's example:

<http://location.data.ex/so/ad/AddressRepresentation/54321>
  a locn:Address ;
  locn:locatorDesignator "11B"^^xsd:string ;
  locn:locatorDesignator [
    locn:locatorDesignatorValue "11"^^xsd:string ;
    dct:type <
http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumber
>
  ] ;
  locn:locatorDesignator [
    locn:locatorDesignatorValue "B"^^xsd:string ;
    dct:type <
http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumberExtension
>
  ] .

WDYT?

Andrea

----
[1]
http://inspire-twg.jrc.ec.europa.eu/data-model/approved/r937/EARoot/EA2/EA3/EA1/EA7262.html
[2]http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue


On Fri, Jan 31, 2014 at 3:36 PM, Stasinos Konstantopoulos <
konstant@iit.demokritos.gr> wrote:

> Maybe a linked list of designators would work, if one is willing to pay
> the complexity price. So for "Sesame st. 11B" you would have gotten
> something like:
>
> http://address/sesame_street/11B locn:locatorDesignator [
>   locn:locatorDesignatorValue "11";
>   locn:locatorDesignator [
>       locn:locatorDesignatorValue "B";
>       locn:locatorDesignator locn:null
>   ]
> ] .
>
> and for house 2C at Sesame st. 11:
>
> http://address/sesame_street/11B locn:locatorDesignator [
>   locn:locatorDesignatorValue "11";
>   locn:locatorDesignator [
>     locn:locatorDesignatorValue "2";
>     locn:locatorDesignator [
>       locn:locatorDesignatorValue "C";
>       locn:locatorDesignator locn:null
>     ]
>   ]
> ] .
>
> and so on.
>
> Stasinos
>
>
> On Fri Jan 24 16:26:05 2014 Bart van Leeuwen said:
>
> > Hi Frans,
> >
> > I've been strugling with the same issue:
> > http://data.resc.info/bag/page/adres/363200000453365
> >
> > I did use a double designator, and for the dutch situation I use the
> > xsd:decimal as recognition of the first part.
> > And yes thats a ugly hack, besides that I'm not sure if it is possible to
> > have both a house number and a house letter as well.
> > That wouldn't work in this case.
> >
> > Any guidance on this one would be nice.
> >
> > Met Vriendelijke Groet / With Kind Regards
> > Bart van Leeuwen
> >
> > ##############################################################
> > # twitter: @semanticfire
> > # netage.nl
> > # http://netage.nl
> > # Enschedepad 76
> > # 1324 GJ Almere
> > # The Netherlands
> > # tel. +31(0)36-5347479
> > ##############################################################
> >
> >
> >
> > From:   Frans Knibbe | Geodan <frans.knibbe@geodan.nl>
> > To:     LocAdd W3C CG Public Mailing list <public-locadd@w3.org>
> > Date:   24-01-2014 16:15
> > Subject:        Trying  to use locn:locatorDesignator
> >
> >
> >
> > Hello,
> >
> > I am working on a case where I need to publish addresses. A fine
> > opportunity to use the locn vocabulary! But I think I could use some
> > help on the usage of locn:locatorDesignator.
> >
> > Let's say I have an address "Sesame street 11 B". The locn:thoroughfare
> > would then be "Sesame street" and I think "11" and "B" are
> > locn:locatorDesignators. Now I could make it easy to say that "11 B" is
> > a single locn:locatorDesignator, but the national registry for addresses
> > in the Netherlands considers them separate things, a number and an
> > extension. So it is desirable to keep them separate. So how do I publish
> > the two designators? The order is important, because "Sesame street B
> > 11" is nonsense.
> >
> > I believe INSPIRE uses code list to distinguish different kinds of
> > locator designators. How can locn handle this case?
> >
> > Regards,
> > Frans
> >
> >
> >
> >
>
>


-- 
Andrea Perego, Ph.D.
European Commission DG JRC
Institute for Environment & Sustainability
Unit H06 - Digital Earth & Reference Data
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

DE+RD Unit: http://ies.jrc.ec.europa.eu/DE

----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.