We probably need to agree on the terms for data and metadata. Anthony is mnot keen on “stuff” but what better term have we got?? Also metadata sounds too technical: how abour properties?
I can see SETS can be hierarchical, chronological, etc. But what about TAGS and SETS. Do TAGS and SETS sit in one big pool for searching or are they themselves navigatable and placeable into hierchical boxes?
I dont think we should expose the user to the term metadata at all! Tags, keywords, labels – anything but metadata. However, for the model above which is aimed at technical people, and the project team, metadata makes sense. Of course metadata is in fact data. So we only really have data and interface! Metadata is a type of data as well as being data about data. Anything that can be done to metadata (edit, delete, add..) can also be done to data.
Tags and sets are flat. I envision a manay-to-many relationship. This also allows for a perceived hierarchy as far as the end user is concerned. They can physically order their stuff however they like. The metadata adjusts accordingly.
Happy with your view on metadata. But we still need to think about what the users see. I can imagine they browse “stuff”, data, tags and sets, but for each of those they need and can edit metadata? What do we call the metadata set associated to each stuff?
Happy with Tags and Sets being flat and with relationships allowing the perceieved hierarhcy. In which case, I would say some SETS are designed to be deliberatly hierarhical. We may create a SET called Folder which exposes a Folder/File hierarchy for example.
Yes indeed. I think we’re at a good stage for me to draw some more screens since we seem pretty happy with the technical bits behind this. I guess most of this initial work ensures our thinking is fairly unified.