Hi all, We are also facing similar issues so I completely agree with this feature. In fact, we added recently in our service layer a new field for our metadata called "format", we needed this field to specify different format types for the dates returned by our datastores.
However, I'm not really sure how to implement this feature... I guess we should keep getting the metadata "core" from our datasources but what about the new metadata??: - How to fill it out? Will the integrator of MM provide functions to define when an element is going to be "x" and when is going to be "y"? (thinking here of providing lambda functions) - Do we really need a metadata store? Kind regards, 2015-07-10 12:51 GMT+02:00 Kasper Sørensen <[email protected]>: > Hi all, > > All the time I see more and more need for us to add metadata to our > MetaModel based connectors. That could be for instance metadata about scale > (nominal, ordinal etc.) so that we can automate some stats collection etc. > or it could be more "meaning" oriented features to describe e.g. "This is a > first name" or "This is a city" or "These two fields (first and last name) > are together defining a name of a person". > > We have such mechanisms in our application levels many places, but not at > the core framework of MetaModel and that's a pity because it makes it > harder for us to share. > > So I'm thinking of adding such a layer to the metadata of MetaModel. But > one thing that's difficult is then about representing that metadata in some > "metadata store" which isn't necesarily the same as the data source itself. > It could be an XML file or it could be a complete metadata database. And I > think that this metadata would be mutable by the integrator of MetaModel > because it is rarely fully revealed by the data source itself. > > What do you think? Nice feature or?` > > Kasper >
