[ldap] Re: ldap attribute for continent?

[Ivan Shmakov]

> Hallvard B Furuseth  writes:

[...]

 >>> * Create an attribute option range "coordinate-" so
 >>> that you can create one attribute description set for each
 >>> coordinate system:

 >>>   attribute "latitude;coordinate-a",  value "1"
 >>>   attribute "latitude;coordinate-b",  value "2"
 >>>   attribute "latitude;coordinate-c",  value "3"
 >>>   attribute "longitude;coordinate-a", value "9"
 >>>   attribute "longitude;coordinate-b", value "8"
 >>>   attribute "longitude;coordinate-c", value "7"

[...]

 >> OTOH, there'd be no way to make multiple (latitude, longitude) pairs
 >> given a single coordinate system.

 > True.  Well, one could add a distinguising number in the "coordinate"
 > attribute (see example below), but it does get quite cumbersome.

Actually, this restriction is most probably the desired one.

 >> Given the schema above, would it be possible to make an LDAP filter
 >> for the points lying within a rectangular region (like: latitude is
 >> between 50 and 55, longitude is between 79 and 89)?

 > With the values in different attibutes, you can search for

 > (&(latitude>=50)(latitude<=55)(longitude>=79)(longitude<=89))

 > if you define ORDERING matching rules for the attributes.

 > Note however that this doesn't work right with multi-valued attrs,
 > even if you disambiguate them somehow: It will match e.g. this:

 > latitude;coordinate-a-value1:  10
 > longitude;coordinate-a-value1: 20
 > latitude;coordinate-a-value1:  60
 > longitude;coordinate-a-value1: 89.5

 > To get around that you'd need to stuff each position into a separate
 > entry.

ACK.  Thanks.

 > With a single "all in one" position attribute, no it's not possible -
 > unless you write a server plugin which defines a new syntax and
 > matching rule.  Even with simpler searches you need substring search
 > which is more expensive in the server than equality search, and also
 > the filter must somehow distinguish latitude from longitude.

... And also the scarcity of ``filter types'' defined for LDAP
has to play its part.

[...]

 > Also, unless you have a small database you'll want a syntax which the
 > server can index for efficient ORDERING searches.  With OpenLDAP I
 > think that would have to be INTEGER.

So, there's no support for any indexes on floating-point values
in OpenLDAP?

 > Which maybe leads you to create supplementary attributes that can be
 > indexed for ordering, in addition to more detailed attributes with
 > the real values...

... Perhaps, some ``hybrid'' approach could be used.  E. g.:

geoPosition (multi-value): to hold all the possible pairs;
geoLatitudeWGS84,
geoLongitudeWGS84: to hold the WGS 84 coordinates;
geoBBoxNorthWGS84,
geoBBoxSouthWGS84,
geoBBoxWestWGS84,
geoBBoxEastWGS84: to hold the WGS 84 bounding box.

The first attribute is to be the ``payload'' one, and the rest
will facilitate filtering.  It'd be up to the client to maintain
them in sync.

 > An entirely different approach would be to store this in an SQL
 > database on the server and define some magic filter strings that
 > translate into proper SQL searches, where you can do complex
 > filtering like that.  That way you'll in effect just be using LDAP as
 > a cumbersome access control to SQL.  Don't know if any LDAP servers
 > support that though.

I hope it won't be necessary.

-- 
FSF associate member #7257

[ldap] Re: ldap attribute for continent?

[Hallvard B Furuseth]

Ivan Shmakov writes:
> > Hallvard B Furuseth  writes:
> 
>  > Solutions:
>  > * Make a single attribute with all three values.
>  >   attribute "position", values ("a 1 9", "b 2 8", "c 3 7").
>  > Syntax Directory String or IA5 String, plus a client-defined syntax
>  > which clients are responsible for writing and parsing.
> 
>   Any particular reason not to have a multi-value attribute?

Client requirements, if some clients wants each value in a single
attribute.

Filtering, as you mention below.

>  > * Create an attribute option range "coordinate-" so that
>  > you can create one attribute description set for each coordinate
>  > system:
>  >   attribute "latitude;coordinate-a",  value "1"
>  >   attribute "latitude;coordinate-b",  value "2"
>  >   attribute "latitude;coordinate-c",  value "3"
>  >   attribute "longitude;coordinate-a", value "9"
>  >   attribute "longitude;coordinate-b", value "8"
>  >   attribute "longitude;coordinate-c", value "7"
> 
>   IIUC, this will preclude the DSA from maintaining consistency,
>   as nothing's going to prevent the client from inserting, e. g.,
>   latitude;coordinate-a but not longitude;coordinate-a?

Right.  But then, nothing prevents the client from creating position
attributes either, since syntax checking is on the client side.

>   OTOH, there'd be no way to make multiple (latitude, longitude)
>   pairs given a single coordinate system.

True.  Well, one could add a distinguising number in the "coordinate"
attribute (see example below), but it does get quite cumbersome.

>   Given the schema above, would it be possible to make an LDAP
>   filter for the points lying within a rectangular region (like:
>   latitude is between 50 and 55, longitude is between 79 and 89)?

With the values in different attibutes, you can search for

   (&(latitude>=50)(latitude<=55)(longitude>=79)(longitude<=89))

if you define ORDERING matching rules for the attributes.
Note however that this doesn't work right with multi-valued attrs,
even if you disambiguate them somehow:  It will match e.g. this:

latitude;coordinate-a-value1:  10
longitude;coordinate-a-value1: 20
latitude;coordinate-a-value1:  60
longitude;coordinate-a-value1: 89.5

To get around that you'd need to stuff each position into a separate
entry.
 

With a single "all in one" position attribute, no it's not possible -
unless you write a server plugin which defines a new syntax and matching
rule.  Even with simpler searches you need substring search which is
more expensive in the server than equality search, and also the filter
must somehow distinguish latitude from longitude.  Come to think of it,
putting N and W in front of the numbers will help that a bit -- front
rather than back to make search for an approximate location possible.
Filter *W23* is more helpful than "*23*W*".


Also, unless you have a small database you'll want a syntax which the
server can index for efficient ORDERING searches.  With OpenLDAP I think
that would have to be INTEGER.  Which maybe leads you to create
supplementary attributes that can be indexed for ordering, in addition
to more detailed attributes with the real values...


An entirely different approach would be to store this in an SQL database
on the server and define some magic filter strings that translate into
proper SQL searches, where you can do complex filtering like that.  That
way you'll in effect just be using LDAP as a cumbersome access control
to SQL.  Don't know if any LDAP servers support that though.

-- 
Hallvard

[ldap] Re: ldap attribute for continent?

[Ivan Shmakov]

> Michael Ströder  writes:
> Ivan Shmakov wrote:
> Michael Ströder  writes:

[...]

 >>> But encouraging all the LDAP server vendors to implement an
 >>> additional syntax can take some time. ;-)

 >> The system I'm working on is going to have somewhat narrow field of
 >> use, so, in practice, it would probably be sufficient to provide a
 >> single implementation (did I say OpenLDAP?) supporting the syntax.

 > So you'd have to implement that LDAP syntax for OpenLDAP and
 > preferrably contribute it to the OpenLDAP project.

Surely.  Adapting patches to the every new version of the
package forever is definitely off my plans.

 > Note that it would be helpful if you write an Internet Draft for it
 > and pushing it to at least an informational RFC.

Hopefully I'd be able to do at least the technical part.  The
whole system is in, what I'd call it, the ``deep research''
stage.

 >> The question is, how would an LDAP DSA (DUA) treat attributes having
 >> the syntax unknown to it?  Would it, e. g., simply treat their
 >> values as binary strings?

 > No.  An attribute type description contains a reference to the SYNTAX
 > by OID.  OpenLDAP won't even start if the syntax is not implemented.

[...]

 > Another approach in OpenLDAP is to use slapo-constraint to let the
 > DSA check whether the attribute values match additional constraints
 > (see man page).  Again for composed attribute values only a regex
 > checking would be applicable.

ACK.  Thanks.

[...]

 >>> for all the coordinate systems and encourage people to register
 >>> their coordinate systems.

 >> This could be the easiest part, as there're already developed
 >> ``vocabularies'' of coordinate systems.  In particular, I believe
 >> WKT [1] uses one.

 >> [1] http://en.wikipedia.org/wiki/Well-known_text

 > I'm not familiar with this stuff but it's good to rely on existing
 > and well-maintained registries.

Yes.

-- 
FSF associate member #7257

[ldap] Re: LDAP attributes for geographic ``variables''?

[Ivan Shmakov]

> Kurt Zeilenga  writes:

[...]

 > As an alternative approach, I would suggest having a single
 > multi-valued attribute that would contain URIs expressing the
 > location of the attribute.  This would push various issues, such as
 > which location system is being used, out to the URIs.  This is a good
 > thing as such issues are not unique to LDAP/X.500.

I've never heard of the geographic coordinates being encoded as
an URI.  Could you please give any references on that matter (if
there're any)?

-- 
FSF associate member #7257

[ldap] Re: LDAP attributes for geographic ``variables''?

[Kurt Zeilenga]

On Jul 27, 2009, at 11:16 AM, Michael Ströder wrote:


Kurt Zeilenga wrote:
As an alternative approach, I would suggest having a single multi- 
valued

attribute that would contain URIs expressing the location of the
attribute.   This would push various issues, such as which location
system is being used, out to the URIs.  This is a good thing as such
issues are not unique to LDAP/X.500.


Is there anything like this already defined/used somewhere?


The geo: URI is a work in progress .


I think it would be good to define an LDAP/X.500 attribute type to  
hold any URI that represents the geographical location of the object,  
recommending use of geo: but allow for other schemes as might become  
available.


Of course, one could just put a geo: URI in labeledURI... but I don't  
recommend doing this.


-- Kurt

[ldap] Re: ldap attribute for continent?

[Ivan Shmakov]

> Hallvard B Furuseth  writes:

 >> * allow any number of (coordinate system, latitude, longitude)
 >> triplets to be specified.

 >> The last approach seems to be the most flexible.  However, I don't
 >> know if it's possible to ``tie'' attributes into such a ``triples''
 >> with LDAP?

 > Like this?

 >   attribute "coordSys",  values ("a", "b", "c")
 >   attribute "latitude",  values ("1", "2", "3")
 >   attribute "longitude", values ("9", "8", "7")

 > Nope... an attribute's values are in an unordered list, so LDAP is
 > free to mess that up.

I've suspected that.  Thanks.

 > Solutions:

 > * Make a single attribute with all three values.

 >   attribute "position", values ("a 1 9", "b 2 8", "c 3 7").

 > Syntax Directory String or IA5 String, plus a client-defined syntax
 > which clients are responsible for writing and parsing.

Any particular reason not to have a multi-value attribute?

  attribute "position", value "a 1 9"
  attribute "position", value "b 2 8"
  attribute "position", value "c 3 7"

 > Or if you really want separate attributes (I'd not do that unless I
 > needed to):

 > * Create one entry for each coordinate system, and put each variant
 > in a separate entry.

 > * Create an attribute option range "coordinate-" so that
 > you can create one attribute description set for each coordinate
 > system:

 >   attribute "latitude;coordinate-a",  value "1"
 >   attribute "latitude;coordinate-b",  value "2"
 >   attribute "latitude;coordinate-c",  value "3"
 >   attribute "longitude;coordinate-a", value "9"
 >   attribute "longitude;coordinate-b", value "8"
 >   attribute "longitude;coordinate-c", value "7"

IIUC, this will preclude the DSA from maintaining consistency,
as nothing's going to prevent the client from inserting, e. g.,
latitude;coordinate-a but not longitude;coordinate-a?

OTOH, there'd be no way to make multiple (latitude, longitude)
pairs given a single coordinate system.

Given the schema above, would it be possible to make an LDAP
filter for the points lying within a rectangular region (like:
latitude is between 50 and 55, longitude is between 79 and 89)?

 > This may require server support for user-defined attribute options
 > though.  E.g. the "attributeoptions" keyword in OpenLDAP slapd.conf.

ACK.  Thanks.

-- 
FSF associate member #7257

[ldap] Re: LDAP attributes for geographic ``variables''?

[Michael Ströder]

Kurt Zeilenga wrote:
> As an alternative approach, I would suggest having a single multi-valued
> attribute that would contain URIs expressing the location of the
> attribute.   This would push various issues, such as which location
> system is being used, out to the URIs.  This is a good thing as such
> issues are not unique to LDAP/X.500.

Is there anything like this already defined/used somewhere?

Ciao, Michael.

[ldap] Re: ldap attribute for continent?

[Michael Ströder]

Ivan Shmakov wrote:
>> Michael Ströder  writes:
>  > Defining your own LDAP syntax would be the solution (similar to
>  > RFC2307 NIS Netgroup Triple, OID 1.3.6.1.1.1.0.0).
> 
>   ACK.  Thanks.
> 
>  > But encouraging all the LDAP server vendors to implement an
>  > additional syntax can take some time. ;-)
> 
>   The system I'm working on is going to have somewhat narrow field
>   of use, so, in practice, it would probably be sufficient to
>   provide a single implementation (did I say OpenLDAP?) supporting
>   the syntax.

So you'd have to implement that LDAP syntax for OpenLDAP and preferrably
contribute it to the OpenLDAP project. Note that it would be helpful if
you write an Internet Draft for it and pushing it to at least an
informational RFC.

>   The question is, how would an LDAP DSA (DUA) treat attributes
>   having the syntax unknown to it?  Would it, e. g., simply treat
>   their values as binary strings?

No. An attribute type description contains a reference to the SYNTAX by
OID. OpenLDAP won't even start if the syntax is not implemented. So for
a syntax not implemented in a DSA you might work around it by changing
the attribute type description to use a syntax implemented in a specific
DSA. But then you loose syntax checking.

Also in OpenLDAP you can define a substituted syntax (see ITS#5663). But
again there's no syntax checking.

Another approach in OpenLDAP is to use slapo-constraint to let the DSA
check whether the attribute values match additional constraints (see man
page). Again for composed attribute values only a regex checking would
be applicable.

>  > Also it would require to define name/ID registry
> 
>   Do you mean anything specific by ``ID'' here?

Just a well-known and unique identifier for a coordinate system.

>  > for all the coordinate systems and encourage people to register their
>  > coordinate systems.
> 
>   This could be the easiest part, as there're already developed
>   ``vocabularies'' of coordinate systems.  In particular, I
>   believe WKT [1] uses one.
> 
> [1] http://en.wikipedia.org/wiki/Well-known_text

I'm not familiar with this stuff but it's good to rely on existing and
well-maintained registries.

Ciao, Michael.

[ldap] Re: LDAP attributes for geographic ``variables''?

[Kurt Zeilenga]

As an alternative approach, I would suggest having a single multi- 
valued attribute that would contain URIs expressing the location of  
the attribute.   This would push various issues, such as which  
location system is being used, out to the URIs.  This is a good thing  
as such issues are not unique to LDAP/X.500.


-- Kurt


On Jul 27, 2009, at 10:19 AM, Ivan Shmakov wrote:


Adam Tauno Williams  writes:


Hello. Is there a standardized (or regularly used) attribute  
defined for

continents, besides country, st, locality?



Not that I've ever seen.  There are a couple of definitions of
longitude/latitude floating about, but nothing for continent.


I wonder, what other geographic ``variables'' (or objects?) have
found their way to LDAP?  To put it differently, the (latitude,
longitude) pair describes a point on the Earth's surface.  Are
there existing LDAP attributes (or object classes?) that will
allow one to describe more complex ``features'' upon the Earth's
surface, such as, e. g., polygons?


Debian:



attributetype ( 1.3.6.1.4.1.9586.100.4.2.7
   NAME 'latitude'
   DESC 'latitude coordinate'
   EQUALITY caseExactIA5Match
   SUBSTR caseExactIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )


And also:

--cut: http://openosi.org/osi/display/oid/1.3.6.1.4.1.27630.2.1.1.23  
--

attributetype ( 1.3.6.1.4.1.27630.2.1.1.23
   NAME ( 'osiLatitude' 'latitude'  )
   DESC 'Latitude in decimal degree notation, negative sign for  
South'

   EQUALITY caseExactIA5Match
   SUBSTR caseExactIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
   SINGLE-VALUE )

...

  SYNONYM OID
* 1.3.6.1.4.1.9586.100.4.2.7 (Debian userdir-ldap.schema)
--cut: http://openosi.org/osi/display/oid/1.3.6.1.4.1.27630.2.1.1.23  
--


[...]


GNOME has defined it as well:



attributetype ( 1.3.6.1.4.1.3319.7.7
   NAME 'latitude'
   DESC 'latitude coordinate'
   EQUALITY caseExactIA5Match
   SUBSTR caseExactIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )


Seems to be not used much, as Google lists only two matches for
the OID.

[...]

--
FSF associate member #7257

[ldap] Re: real world object -> DN: an one-to-many mapping?

[Ivan Shmakov]

> Michael Ströder  writes:

 >> It seems that the cases when the same real world object is described
 >> by several DIT entries are not uncommon.

 >> The only thing that comes to my mind is a separate multi-value
 >> attribute holding the DNs of all the DIT entries known to describe
 >> the same real-world object, like:

 >> ( ... NAME 'knownOtherObjectName'
 >>   EQUALITY distinguishedNameMatch
 >>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

 > There is already an attribute type defined like that in section
 > 2.30. of RFC 4519.  Not sure whether that is the right approach for
 > your particular application though.

I'm not quite sure that this attribute is appropriate.

From its description below it's clear that this attribute is to
hold references to the entries corresponding to the real-world
objects that are (somehow) related to the given real-world
object.  The attribute I had in mind is either more specific or
(if ``related'' is specifically prohibited from carrying the
meaning ``being the same'') completely different.

Therefore, using `seeAlso' in such a way would, at least,
confuse potential users of the data.

--cut: http://www.rfc-editor.org/rfc/rfc4519.txt --
2.30.  'seeAlso'

   The 'seeAlso' attribute type contains the distinguished names of
   objects that are related to the subject object.  Each related object
   name is one value of this multi-valued attribute.
   (Source: X.520 [X.520])

  ( 2.5.4.34 NAME 'seeAlso'
 SUP distinguishedName )

...

   Example: The person object "cn=James Brown,ou=employee,o=Widget\,
Inc." is related to the role objects "cn=Football Team
Captain,ou=sponsored activities,o=Widget\, Inc." and
"cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
Since the role objects are related to the person object, the
'seeAlso' attribute will contain the distinguished name of
each role object as separate values.
--cut: http://www.rfc-editor.org/rfc/rfc4519.txt --

-- 
FSF associate member #7257

[ldap] Re: ldap attribute for continent?

[Ivan Shmakov]

> Michael Ströder  writes:

[...]

 >> * designate some ``standard coordinate system'' (like: WGS 84) for
 >> the attributes (like: `latitudeWGS84', `longitudeWGS84'); convert
 >> the values on the client side whenever a non-standard coordinate
 >> system is to be used;

[...]

 >> To my mind, the first approach leads to potential information loss,
 >> as there may be rounding errors in the conversion process, or there
 >> could simply be no conversion function at the moment when the data
 >> is to be stored.

 > Hmm, from the schema design approach I'd prefer the first
 > possibility.

Actually, I haven't investigated on these conversions much, so
I'm not sure that it would always be ``appropriate'' (from a
geographer's standpoint) to perform such a conversion.

 >> The last approach seems to be the most flexible.  However, I don't
 >> know if it's possible to ``tie'' attributes into such a ``triples''
 >> with LDAP?  Should these triplets be granted its own syntax and,
 >> consequently, an attribute? (like: geoSurfacePoint.)

 > Defining your own LDAP syntax would be the solution (similar to
 > RFC2307 NIS Netgroup Triple, OID 1.3.6.1.1.1.0.0).

ACK.  Thanks.

 > But encouraging all the LDAP server vendors to implement an
 > additional syntax can take some time. ;-)

The system I'm working on is going to have somewhat narrow field
of use, so, in practice, it would probably be sufficient to
provide a single implementation (did I say OpenLDAP?) supporting
the syntax.

The question is, how would an LDAP DSA (DUA) treat attributes
having the syntax unknown to it?  Would it, e. g., simply treat
their values as binary strings?

 > Also it would require to define name/ID registry

Do you mean anything specific by ``ID'' here?

 > for all the coordinate systems and encourage people to register their
 > coordinate systems.

This could be the easiest part, as there're already developed
``vocabularies'' of coordinate systems.  In particular, I
believe WKT [1] uses one.

[1] http://en.wikipedia.org/wiki/Well-known_text

-- 
FSF associate member #7257

[ldap] Re: ldap attribute for continent?

[Hallvard B Furuseth]

Ivan Shmakov writes:
> (...)
>   * allow any number of (coordinate system, latitude, longitude)
> triplets to be specified.
> (...)
>   The last approach seems to be the most flexible.  However, I
>   don't know if it's possible to ``tie'' attributes into such a
>   ``triples'' with LDAP?

Like this?
  attribute "coordSys",  values ("a", "b", "c")
  attribute "latitude",  values ("1", "2", "3")
  attribute "longitude", values ("9", "8", "7")
Nope... an attribute's values are in an unordered list, so LDAP is
free to mess that up.

Solutions:

* Make a single attribute with all three values.
  attribute "position", values ("a 1 9", "b 2 8", "c 3 7").

  Syntax Directory String or IA5 String, plus a client-defined syntax
  which clients are responsible for writing and parsing.

Or if you really want separate attributes (I'd not do that unless I
needed to):

* Create one entry for each coordinate system, and put each variant
  in a separate entry.

* Create an attribute option range "coordinate-"
  so that you can create one attribute description set for each
  coordinate system:

  attribute "latitude;coordinate-a",  value "1"
  attribute "latitude;coordinate-b",  value "2"
  attribute "latitude;coordinate-c",  value "3"
  attribute "longitude;coordinate-a", value "9"
  attribute "longitude;coordinate-b", value "8"
  attribute "longitude;coordinate-c", value "7"

  This may require server support for user-defined attribute options
  though.  E.g. the "attributeoptions" keyword in OpenLDAP slapd.conf.

-- 
Hallvard

[ldap] Re: real world object -> DN: an one-to-many mapping?

[Michael Ströder]

Ivan Shmakov wrote:
>   It seems that the cases when the same real world object is
>   described by several DIT entries are not uncommon.
> [..]
>   The only thing that comes to my mind is a separate multi-value
>   attribute holding the DNs of all the DIT entries known to
>   describe the same real-world object, like:
> 
>   ( ... NAME 'knownOtherObjectName'
> EQUALITY distinguishedNameMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

There is already an attribute type defined like that in section 2.30. of
RFC 4519. Not sure whether that is the right approach for your
particular application though.

-- 
Michael Ströder
E-Mail: mich...@stroeder.com
http://www.stroeder.com

[ldap] Re: ldap attribute for continent?

[Michael Ströder]

Ivan Shmakov wrote:
>   ... One of the biggest shocks I've ever experienced in my life
>   was caused by the observation that there's /infinite/ /number/
>   of (latitude, longitude) pairs for (almost) any given point on
>   the Earth surface, depending on the reference ellipsoid [1]
>   being used.  IOW, there's no point in talking of any latitude
>   value before the reference ellipsoid has been specified (though
>   WGS 84 [2] is probably the one used most often.)
> 
>   This leads me to a question: given that a given object may have
>   several (latitude, longitude) pairs, what would be the best way
>   to deal them with LDAP?  I could imagine the following
>   solutions:
> 
>   * designate some ``standard coordinate system'' (like: WGS 84)
> for the attributes (like: `latitudeWGS84', `longitudeWGS84');
> convert the values on the client side whenever a non-standard
> coordinate system is to be used;
> 
>   * allow any coordinate system, which then should be specified by
> a separate attribute;
> 
>   * allow any number of (coordinate system, latitude, longitude)
> triplets to be specified.
> 
>   To my mind, the first approach leads to potential information
>   loss, as there may be rounding errors in the conversion process,
>   or there could simply be no conversion function at the moment
>   when the data is to be stored.

Hmm, from the schema design approach I'd prefer the first possibility.

>   The last approach seems to be the most flexible.  However, I
>   don't know if it's possible to ``tie'' attributes into such a
>   ``triples'' with LDAP?  Should these triplets be granted its own
>   syntax and, consequently, an attribute? (like: geoSurfacePoint.)

Defining your own LDAP syntax would be the solution (similar to RFC2307
NIS Netgroup Triple, OID 1.3.6.1.1.1.0.0). But encouraging all the LDAP
server vendors to implement an additional syntax can take some time. ;-)

Also it would require to define name/ID registry for all the coordinate
systems and encourage people to register their coordinate systems.

Ciao, Michael.

-- 
Michael Ströder
E-Mail: mich...@stroeder.com
http://www.stroeder.com

[ldap] real world object -> DN: an one-to-many mapping?

[Ivan Shmakov]

It seems that the cases when the same real world object is
described by several DIT entries are not uncommon.  E. g., a
person may work in an organization, and for the purposes of this
organization be described by an entry and be a member of some
project, and be described by a different entry as well.  As
different naming contexts represent different administrative
contexts this seems to be inevitable.

For the application I'm currently developing it would be
necessary to allow for the information about some specific
real-world objects to be described by (potentially) arbitrary
number of DIT entries, administred by different real-world
entities.  However, occasionally it would be necessary to
consider different entries describing the same real-world
object.

How do I facilitate the search for the DIT entries describing
the same object as a specified DIT entry?

The only thing that comes to my mind is a separate multi-value
attribute holding the DNs of all the DIT entries known to
describe the same real-world object, like:

  ( ... NAME 'knownOtherObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

Any other ideas?

-- 
FSF associate member #7257

[ldap] Re: ldap attribute for continent?

[Ivan Shmakov]

> Adam Tauno Williams  writes:

 >> Hello. Is there a standardized (or regularly used) attribute defined
 >> for continents, besides country, st, locality?

 > Not that I've ever seen.  There are a couple of definitions of
 > longitude/latitude floating about, but nothing for continent.

 > Debian:

 > attributetype ( 1.3.6.1.4.1.9586.100.4.2.7
 > NAME 'latitude'
 > DESC 'latitude coordinate'
 > EQUALITY caseExactIA5Match
 > SUBSTR caseExactIA5SubstringsMatch
 > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

[...]

... One of the biggest shocks I've ever experienced in my life
was caused by the observation that there's /infinite/ /number/
of (latitude, longitude) pairs for (almost) any given point on
the Earth surface, depending on the reference ellipsoid [1]
being used.  IOW, there's no point in talking of any latitude
value before the reference ellipsoid has been specified (though
WGS 84 [2] is probably the one used most often.)

This leads me to a question: given that a given object may have
several (latitude, longitude) pairs, what would be the best way
to deal them with LDAP?  I could imagine the following
solutions:

* designate some ``standard coordinate system'' (like: WGS 84)
  for the attributes (like: `latitudeWGS84', `longitudeWGS84');
  convert the values on the client side whenever a non-standard
  coordinate system is to be used;

* allow any coordinate system, which then should be specified by
  a separate attribute;

* allow any number of (coordinate system, latitude, longitude)
  triplets to be specified.

To my mind, the first approach leads to potential information
loss, as there may be rounding errors in the conversion process,
or there could simply be no conversion function at the moment
when the data is to be stored.

The last approach seems to be the most flexible.  However, I
don't know if it's possible to ``tie'' attributes into such a
``triples'' with LDAP?  Should these triplets be granted its own
syntax and, consequently, an attribute? (like: geoSurfacePoint.)

[1] http://en.wikipedia.org/wiki/Reference_ellipsoid
[2] http://en.wikipedia.org/wiki/WGS_84

-- 
FSF associate member #7257

[ldap] LDAP attributes for geographic ``variables''?

[Ivan Shmakov]

> Adam Tauno Williams  writes:

 >> Hello. Is there a standardized (or regularly used) attribute defined for
 >> continents, besides country, st, locality?

 > Not that I've ever seen.  There are a couple of definitions of
 > longitude/latitude floating about, but nothing for continent.

I wonder, what other geographic ``variables'' (or objects?) have
found their way to LDAP?  To put it differently, the (latitude,
longitude) pair describes a point on the Earth's surface.  Are
there existing LDAP attributes (or object classes?) that will
allow one to describe more complex ``features'' upon the Earth's
surface, such as, e. g., polygons?

 > Debian:

 > attributetype ( 1.3.6.1.4.1.9586.100.4.2.7
 > NAME 'latitude'
 > DESC 'latitude coordinate'
 > EQUALITY caseExactIA5Match
 > SUBSTR caseExactIA5SubstringsMatch
 > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

And also:

--cut: http://openosi.org/osi/display/oid/1.3.6.1.4.1.27630.2.1.1.23 --
attributetype ( 1.3.6.1.4.1.27630.2.1.1.23
NAME ( 'osiLatitude' 'latitude'  )
DESC 'Latitude in decimal degree notation, negative sign for South'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

...

   SYNONYM OID
 * 1.3.6.1.4.1.9586.100.4.2.7 (Debian userdir-ldap.schema)
--cut: http://openosi.org/osi/display/oid/1.3.6.1.4.1.27630.2.1.1.23 --

[...]

 > GNOME has defined it as well:

 > attributetype ( 1.3.6.1.4.1.3319.7.7
 > NAME 'latitude'
 > DESC 'latitude coordinate'
 > EQUALITY caseExactIA5Match
 > SUBSTR caseExactIA5SubstringsMatch
 > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Seems to be not used much, as Google lists only two matches for
the OID.

[...]

-- 
FSF associate member #7257