As I sat down and started to think about creating a new feature in my application, I started to consider how it should fit into my framework. It occurred to me that I need to clarify my thoughts on the meaning of semantics, and most particularly the "card" semantic. (keep in mind, I mostly refer to my experience building http://www.passportedu.com in this blog. You might want to take a look at it.)
Cards are a Great Visual Tool
Cards are a popular way of semantically organizing data. The semantic is broad and fairly abstract, until you start adding nouns: i.e. map card, student card, passport card, weather card. You may have seen or heard of the card semantic on applications like Google plus, Facebook, or even Pinterest. The idea of a card is that it is a small modular element of information that can be easily viewed on a mobile device, and even tiled or arranged on a desktop version of the site.
The benefits go a bit deeper than that. Cards are nice because they unify the design of the information displaying on your site. Cards make it easy to take some information from one page and use it in another page. You can just copy the card over, it's easy. Cards leave you with a nice inheritance model, where the stacking and arranging of the cards can be handled by one level of semantic markup, while the presentation of each card can be handled by its own semantics within the card.
Transform Semantics from Models
Is there a need to organize your domain-data in the same card-like way. As I notice, you may also notice that the semantics of cards have mostly to do with the display of information. Do you need a cards table/collection? The short answer is No! The data should not conform to the semantic. At least in the card case, the semantic is mostly visual. A card is primarly a way to display information. As a means of keeping information, perhaps there are better ways.
Understand Some Semantics Are Purely Visual
As a justaposition, consider navigation as a semantic. The navigation semantic manifests itself as a navigation bar at the top of the page. I store the navigation links in the schema for each endpoint/page. Thus, for the navigation, there is not really a database.
Now, consider the paging semantic. This semantic manifests on http://www.passportedu.com when paging data, and an accompanying schema link appear, and are interpolated into a set of links tagged with the "paging" semantic. This data is derived from some static schema and some dynamic data, based on the context.
Mentally Separate the Visual from the Model
As you can, see these three semantics all carry a sort of different relation to the underlying data. Yet, they all manifest visually, and have a specific functional meaning. however, they each have an abstraction from the data itself, which may not lend itself to card storage. For instance, the map card, it may be easily visualized in the card semantic, as a map on a card/placard. yet, it is likely best stored alongside other information, perhaps in a school, user, or address object.
Organize the Data in It's Best Form
It may make sense at times to organize the data itself in line with the semantic. However, this isn't necessarily do. it's important to take the benefit of using a semantic abstraction, such that it is suitable to the medium (i.e. display). In the case of the data, such as a school, the schema for the database table/collection contains all the important semantics for storing the data. It's best designed to suit the storage needs of the data, adhering to concerns of normalization, speed, and ease of query.