dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Breaking out from our current hard coded set of object attributes is
certainly a great step forward.  There is also some advantage in
trying to think a bit generally about what we are doing.  We are
seeing lots of progress in the right direction.  I was about to start
a discussion about names earlier, but maybe it makes sense to consider
some of these things together.

In general an entity within the dhis model universe has:
(i) a set of identifiers
(ii) a set of names
(iii) a set of attributes
(iv) a set of relations with other attributes

One could think of names as attributes, but there are reasonable
semantic reasons to consider them separately.

On top of this generic view we have classes or categories of entity.
Such as DataElement, OrgUnit etc, where the class of the entity
determines the set of attributes and the type of relations between
them.

I think from an xml metadata representation perspective, this is
probably how it should be modelled.  The fact that some of the
attributes may be fixed database fields and some dynamically
configured attributes is incidental and purely historical.  If you had
the benefit of hindsight and were designing a datadictionary from
scratch, you might never have had the fixed fields in the database.
Or you might have come up with different ones.  On import/export I
think the distinction should simply be masked by the API.  Fixed or
non-fixed is an internal arrangement of little interest outside the
system.

Bob

PS.  One of the possible uses of attributes which I am seeing is the
in fact the possibility of dynamically adding new identifiers for
objects.

On 8 September 2011 15:55, Jo Størset <storset@xxxxxxxxx> wrote:
> Thanks for the responses.
>
> So I guess this might very well be a start of a general evolution in the meta model? It might be worth already now thinking a little through the possible consequences of this direction going forward. I think this is something we need :)
>
> As we work through how to represent the meta model in external formats (xml and so on), this might have implications on how generic a model we should create for these formats (and I guess the attribute definitions themselves have to represented in some way). In that context it might make sense to generalize both the objects these attributes apply to and the way we represent atrributes more generally. And also at least look at and specify likely future harmonization now?
>
> Changing the external formats once they are created is much more difficult than changing implementation details, so it might be worth it to think a little bit broader already now.
>
> A minor point - when I saw the term dynamic attributes, I was immediately thinking free-form attributes (more like tags you could put on individual org units). But I guess this is about predefined attribute types applied to (specific) meta objects(?) Maybe just calling it "attributes" might be good enough, if that is what it is?
>
> Jo
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>