Hub info model

[skybristol]

Issues #3 and #4 here present two different takes on an information model to describe hubs, developed in the early stage of our work. They represent a bare minimum of thinking about what a hub provides to the notional ODIS network and some dynamics of its technology. We need to further flesh this idea as we move along to eventually create a database of some kind with this information that will become an important organizing part of our eventual system. Ideally, hubs will eventually advertise themselves on the web with information that can align with this model. In the near term, we can create an abstract registry of information to help us learn from what hubs are doing and work at nudging them toward the developing architecture.

Here are some of the properties/characteristics of hubs that might be important. Please comment on this issue with adjustments to these and other important properties. Keep in mind that we have to fill all this information out somewhere in the near term and maintain it for some time period and that hubs will ultimately need to push this information out on the web in some way, so we probably don't want too complicated an information model.

• Hub type: intent is to help us understand how the network will interface with a given entity; we'd want some type of vocabulary for this; one idea includes classifying hubs as primary or secondary sources of information
• Primary topics/artifacts: these are the primary concepts/artifacts that a given hub is responsible for based on its mission; we initially started building on the types of things cataloged in the ODIS-Cat prototype; we need to consider that different hubs will classify the same logical things with different terms; ODIS will need to consider a complex mapping of topics; a characteristic of these is that they will have a unique identifier (at least within the context of the given hub)
• Secondary topics/info sources: many hubs will likely have secondary information that is not the primary purpose of the hub but that is important on the network, particularly as it may help create linkages between resource pools; these items may have a unique identifier within the context of a hub but likely could/should refer to an identifier provided by some other source that is more directly responsible
• Semantic contributions: some hubs are going to provide new explicit ways of describing their primary artifacts with defined terms/concepts that add value to the overall network Scope: various ways of describing the overall scope of a hub; could be spatial or temporal, topical, organizational, etc.
• Machine access: what kinds of possibilities are there for interfacing with the hub's information assets in terms of APIs, web services, structured data with landing pages, etc.
• Technology family: certain types of tech platforms offer specific types of interfaces or expected capabilities that can be used to help determine how it interfaces on the network

[skybristol]

Another interesting dynamic to add to our model would be some way of capturing an initial notion of what other hubs a given hub needs or wants to connect. This would start to give us a picture of what the network looks like.

In the long run, this should be more of a dynamic way of visualizing and examining the network based on actual information flow and some way of monitoring it. Any hub in the ODIS-powered network should be able to report on what information it is pulling in from any other hub and what uses it is putting that information to, including any value-added content it is able to contribute about the same things. For instance, as we start formalizing, persistently identifying, and building information around research vessels and other platforms, different hubs are going to have different information about and associated with those platforms. Projecting that information online via linked data adds value to the corpus and shows a dynamic, logical linkage between two hubs.