My own view is that the single hierarchical approach is fine for a well
controlled and well defined area: we can define the account systems for a
company using a relational or set of hierarchical structures because it is a
relatively closed problem with one authority who can decide how things will
be represented. For a wide range of groups tackling different problems and
who do not closely interact or are not under a single authority then you
have to accept that each group will define structures that suit their own
field; in this case you need to be able to namespace those structures and
then, when you need to, define how those namespaces are related.
This is now coming up in the semantic web field - there were quite a few papers at ISWC2005 dealing with ontology interoperability and how systems can work with multiple overlapping ontologies.
Cheers,
Tony.
> -----Original Message-----
> From: owner-ucd-at-eso.org [mailto:owner-ucd-at-eso.org] On Behalf
> Of Doug Tody
> Sent: 01 December 2005 20:37
> To: Rob Seaman
> Cc: ucd-at-ivoa.net
> Subject: Re: VOConcepts paper
>
> Right! This is the classical problem of explicit hierarchy
> versus flat or mostly-flat namespaces which are associated in
> a more general fashion (e.g., hierarchical versus relational
> structures). Unless you are trying to model a single complex
> entity it is almost always better to use the relational
> approach where simple, well-defined entites are associated.
> This allows more complex relationships to be described,
> permits multiple views of the same data, and in some cases
> can permit inference. The namespace/mapping approach is a
> good one for vocabularies.
> For structured data one does much the same thing, but the
> namespace in this case is a component data model. - Doug
>
>
>
> On Thu, 1 Dec 2005, Rob Seaman wrote:
> > If UCDs were used to create and track such lists, one could
> attempt to
> > achieve the same many-to-one mapping by relying on the hierarchical
> > nature of
> > UCDs: filter.R.this_is_a_specific_wideband_R_filter. This has
> > problems on both ends. First, there will often be a
> redundant prefix
> > like "filter." and second, who is to say that it is the "R-ness" of
> > the filter that we wish to capture in a short nickname? Perhaps we
> > rather need to capture the "wideband-ness" of the filter.
> The problem
> > with relying on a hierarchy in a single namespace is
> precisely that only one hierarchy exists per namespace.
> > On the other hand, multiple mappings are trivial with
> multiple namespaces.
>
Received on 2005-12-01Z20:59:43