Research on Metadata Standards for AI Models

The breakthrough and rapid development of Artificial Intelligence (AI) technology is undoubtedly a milestone event in the development of global science and technology in recent years. In this process, “model” (Model) is the carrier of AI technology and the landmark achievement. Broadly speaking, “Model” reflects a worldview, which is a simplified, abstract and idealized description of a complex phenomenon or system in the real world [1]. In a narrower sense, a “model” usually refers to a mathematical structure or algorithm that represents a law, pattern, or relationship learned from data. The model extracts patterns and generates insights from a variety of data materials by means of algorithms, constantly adjusting and optimizing the degree of realism of the world it simulates.

However, with the rapid advancement of technology and breakthroughs in computational power, many AI models have become increasingly complex, so much so that even developers often struggle to fully interpret their behavior. This growing complexity has raised concerns regarding the application of AI technologies in certain domains, prompting calls for enhancing model interpretability through the adoption of the FAIR principles [2][3]. The data governance philosophy advocated by the FAIR principles provides an important pathway to improving the interpretability of AI models by ensuring traceability, structured representation, and standardized description of models and their associated data.

Nevertheless, the current FAIR framework is primarily designed for scientific data and remains insufficient when applied to AI model management and interpretability research. In particular, it requires substantial extensions in areas such as algorithm version control, training data management, parameter provenance, and metadata representation of model behavior. Viewing AI models as FAIR Digital Objects not only emphasizes the need for unique identification, accessible mechanisms, and well-structured metadata, but also calls for a systematic representation and governance of all phases of their lifecycle—including training data, training logic, inference engines, and deployment environments. This perspective, which treats AI models as “complex digital objects”, holds promise for advancing interpretability research and trustworthy management practices in areas such as cross-system sharing, regulatory auditing, and accountability attribution.

It is easy to see that there is a gap in expertise between producers and consumers of AI services. AI model metadata, as a tool for describing the characteristics and attributes of a model, plays multiple key roles in the AI ecosystem. First, metadata serves as a “digital identity card”, containing basic key information such as model architecture, training data, performance indicators, and applicable scenarios, which enables users to quickly understand the basic features and capability boundaries of the model. Secondly, metadata provides the necessary “connector” function, enabling the model to be integrated into existing systems. In addition, metadata serves as an “audit trail”. Regulations such as the EU AI Act explicitly require high-risk AI systems to provide technical documentation [4]. All of these requirements are essentially fulfilled by a well-developed metadata system. Overall, metadata plays the role of “control center” in the entire life cycle of AI models, forming the basis of model operation and maintenance.

This paper is centered around the specification of AI model metadata standards. The second part introduces the development of major AI model metadata specifications. The third part describes the application of AI model metadata specifications in mainstream warehousing platforms through comparison. The fourth part then builds on the above work to design an AI model unified metadata ontology.

Overall, the current AI model metadata ecosystem presents a development trend of standardization and fragmentation, and various organizations and platforms are promoting the construction of metadata systems from different perspectives. According to incomplete statistics, there are nearly 20 AI model metadata specifications running on different platforms. These specifications can be categorized into Data Card, System Card, and Model Card. It is important to note that these three classifications are not mutually exclusive; they cover overlapping parts of the AI model lifecycle.

(1) Data Card. AI models are trained using data. The choice of data fundamentally affects the behavior of the model. In practice, data cards are variously called Data Cards, Datasheets, Data Statements, Dataset Nutrition Labels, and Dataset Development Lifecycle Documentation Framework. Data cards seek to answer seven categories of questions: motivation for dataset creation, dataset composition, data collection process, data preprocessing, dataset distribution, dataset maintenance, and legal and ethical considerations. By providing a concise and comprehensive overview of the “ingredients” of data, it lowers the barriers to standardized data analysis, better supports decision-making and accountability, and enables developers and users to better understand the uses and outputs of the model.

(2) System Card. A system card is a metadata specification or documentation tool focused on describing the design of a machine learning system and its underlying algorithms, with the aim of providing system-level technical transparency, reproducibility, and accountability traceability. Unlike data cards and model cards, system cards examine how models interact with each other, with datasets, methods, and with other ML components to form ML systems, including system architecture, algorithmic choices, training strategies, hardware dependencies, performance boundaries, and potential technical ethical risks. System cards are less uniformly named. These are some examples of them: Factsheets, System Cards, Reward Reports for RL, Robustness Gym, ABOUT ML. However, we also found that there are places where system cards and model cards are mixed.

(3) Model Card. As opposed to data cards and system cards, which contain only parts of a model, Model Card seeks to cover the core of an AI model throughout its lifecycle. In 2018, the Google team took the lead in proposing Model Card, a standardized specification framework for metadata for AI models [5]. The implementation and landing of Model Card is an important step forward in Google's efforts to improve the transparency and interpretability of machine learning models. The original idea was to “publish machine learning models with a short one- to two-page record”. In the same year, the World Wide Web Consortium (W3C) proposed a set of specifications for describing Machine Learning (ML) models - ML Schema [6]. Subsequently, other organizations successively introduced their own metadata specifications for AI models. These standard specifications have the same goal and similar content, although there are still differences in consistency, but still better promote the openness and transparency of AI models, and also drive the research and practice in this field.

With regard to the metadata specifications introduced by different organizations, this study conducts a comprehensive comparative analysis of six major model description frameworks proposed or adopted by leading institutions, including Model Card (Google) [5], ML Schema (W3C) [6], AI Factsheet (IBM) [7], AI Service Cards (Amazon) [8], System Card (OpenAI) [9], and Model Card (HuggingFace) [10].

Through the comparative analysis of the above metadata specifications, we draw the following conclusions:

1. Metadata item naming heterogeneity. Metadata item naming heterogeneity refers to the phenomenon of non-uniform naming of metadata items (or fields, attributes) used to describe the same or similar information in six different specifications. This can lead to incompatible and non-interoperable AI model metadata sets.
2. The hierarchical structure is not clear enough. Firstly, there is a lack of unified hierarchical division, i.e., the hierarchical structure varies greatly among different standard specifications, making it difficult to achieve effective comparison, organization and compatibility among different models.
3. Inadequate description and insufficient granularity. The first is that the description is not comprehensive and complete. The fine granularity is coarse and fails to fully capture the key features and complex information of the model, making it difficult to meet the demand for model details in different scenarios.
4. Complex and non-uniform description. Most of the existing standards and specifications use natural language text for description, and a number of information may be described in natural language under a metadata item, which leads to limitations in the scalability of the standard specifications and reduces the efficiency of retrieval using the list of metadata items; secondly, the description is not uniform, and different standards and specifications use different descriptions, which increases the difficulty of interoperability between the specifications and the models.

After combing through the current mainstream AI model metadata standards and specifications, it is not difficult to find that, despite the differences in the content of different standards, their core objectives are highly consistent - that is, to improve the transparency, reusability and traceability of models through structured metadata descriptions.

To examine the application of metadata standards in practice, we selected six of the most representative AI model warehousing platforms at home and abroad - ModelScope, PaddlePaddle, OpenI, Hugging Face, Kaggle, and GitHub. In this study, three types of open source models in the field of natural language processing, Llama, DeepSeek, and Vicuna, are selected for case studies to compare the similarities and differences of their metadata implementations on the above six model warehousing platforms. Although the sample size is limited, considering that the three types of models are more typical, it can initially reveal the usage and problems of model metadata on each platform. In future research, we will expand the sample size by collecting platform data in bulk to further refine or verify the generalizability of the conclusions. Through comparison, we draw the following conclusions:

1. Shared metadata for widely used models. For DeepSeek and Llama, which are more popular AI models, the descriptive metadata information of ModelScope, PaddlePaddle, OpenI, Hugging Face, and GitHub is exactly the same, with 9 primary and 9 secondary classes, indicating that the above storage platforms share the metadata, and only Kaggle adopts its own metadata template. For models that are not so widely used, the metadata adopted by the storage platforms varies greatly. For example, ModelScope, PaddlePaddle, and OpenI have very different metadata description information for the model Vicuna.
2. Except for Kaggle, the other five warehousing platforms will use different metadata descriptive information templates for different AI models, As shown in Table1.
3. Domestic warehousing platforms will process the raw information. For example, PaddlePaddle does a Chinese translation of the content. And ModelScope and OpenI all use English information.

By investigating the mainstream AI model warehousing platforms and the mainstream AI model metadata standard specifications, we can draw some conclusions as follows:

1. Insufficient standardization is the most prominent challenge. So far, there is no unified AI model metadata standard specification to completely cover the mainstream model warehousing platforms, and the existing standard specification has a large degree of dissimilarity.
2. There are significant differences in the metadata schema defined by different organizations and platforms, and there is little overlap of metadata fields between mainstream platforms, and the fragmentation situation greatly increases the overall interoperability cost of the system.
3. There is a gap between the theoretical formulation of metadata specifications and their practical implementation, and there is still room for improvement in the quality and usefulness of metadata.
4. An important feature of AI models is that they undergo continuous iteration and fine-tuning. However, the existing metadata system lacks an effective automatic acquisition and dynamic update mechanism, and version management is not perfect.
5. The sharing of metadata between warehousing platforms is a temporary complementary measure to the current lack of harmonized standards and specifications.

Ontology serves as a critical theoretical foundation and technical framework for metadata standardization. Due to constraints of time and scope, this paper focuses exclusively on the construction of the ontology. aiming to provide a unified semantic foundation for integrating heterogeneous model information. The ontology facilitates the explicit definition of key concepts, attributes, and their relationships within AI models, thereby laying the groundwork for the subsequent design of metadata interoperability mechanisms.

The earliest definition of an ontology was given by Neches in 1991, stating that an ontology defines the basic terms, relations, and rules that constitute a domain's vocabulary, along with the interrelationships among these terms [11]. In 1993, Gruber gave the classic definition of an ontology as an explicitly canonical description of a conceptual model [12]. Subsequently, ontology was introduced into the field of artificial intelligence and five ontology design criteria were given, namely, clarity, consistency, extensibility, minimum coding bias, and minimum ontological commitment [13]. Scholars in various countries have tried to define ontology from different perspectives, but the academic community has not formed a unified definition of ontology for the time being, but it is able to reach some basic consensus that ontology has the basic features such as conceptualization, formalization, clarity, shareability, and domain relevance.

With the in-depth study of ontology construction in academia, many ontology construction methods have been proposed, such as METHONTOLOGY (chemical ontology modeling) [14], Ontology 101 seven-step approach (domain ontology modeling) [15], OBO Foundry Principles (biomedical ontology evolution) [16], and Skeleton Method (business ontology modeling) [17]. In this paper, we are oriented to ontology development for AI models in the field of artificial intelligence, and adopt the seven-step method, which is the most common method for domain ontology, for relevant ontology construction. First of all, it is clear that the research object is AI models - specifically statistical and computational models constructed through data-driven methods, whose core feature is to automatically optimize the parameters through training data to complete specific tasks, and according to the technical paradigm, this research mainly focuses on machine learning models and deep learning models. In order to improve the efficiency of ontology construction, before designing, we combine the characteristics of AI models, give full consideration to reuse existing domain ontologies, and then choose the tool Protege 5.6.5 to complete the visualization of ontology.

Based on the full consideration of existing related ontology models, this paper reuses ML Schema [6] and AI Ontology (AION) [18], and fuses them into four first-level classes, including Model, Data, Task, and Evaluation, and at the same time, we focus on adding three customized first-level classes, including Environment, Accountability, and Personnel, with reference to the relevant specifications such as Model Card [5][19], Data Card [20][21][22], and the EU AI Act [23], to meet the requirements of covering all aspects of AI models. The constructed AI model ontology covers a total of 7 core classes and 22 secondary subclasses, and the conceptual classes and their hierarchical structure are shown in Figure 1.

(1) Model: The Model class is used to describe the basic information and internal structure of the AI model ontology, mainly contains four subclasses, namely: Metadata, Architecture, Parameter and Technique. Metadata describes the basic information of a model, including the model name, release date, update date, and version. Architecture, Parameter, and Technique respectively describes a model's structural design, parameter configuration, and key technologies

(2) Data: The Data class is used to characterize the data resources used in the development, training and evaluation phases of the model, which is an important basis for understanding the training context of the model and evaluating the credibility and fairness of the model. This class contains three subclasses, namely: Training Dataset, Validation Dataset and Evaluation Dataset.

(3) Evaluation: The Evaluation class is used to describe the characteristics of model performance evaluation and contains two subclasses: Metric and Performance, in which Metric is used to define the evaluation indexes used in model evaluation to reveal whether the evaluation method is representative and scientific; Performance is used to characterize the actual performance of the model under specific evaluation conditions to support the credibility release and reproducibility study of the model.

(4) Task: The Task class is used to describe the characteristics of the application tasks undertaken by the model, contains four subclasses: Task Type, Intended Use, Applicability Limitation and In-Out. Task Type describes the task category to which the model belongs; Intended Use describes the target use of the model's design and release, which can be used to identify the model's applicability scenarios; Applicability Limitation specifies the boundaries of the model's use and its exclusion scenarios; In-Out Describe the input-output structure of the model and its technical characteristics, including input-output format, maximum input length and maximum generated output, etc.

(5) Personnel: The Personnel class is used to describe the personnel information related to the development and management of the model, which is an important support for tracking the responsibility and funding background of the model. This class contains three subclasses: Developer, Funder, and Sharer. Developer describes the main developer of the model and the development organization; Funder describes the organization or the source of the project that financed the model development, which helps to identify the potential stakeholders; Sharer refers to the person who shared the model for the first time in public or the person in charge of the release of the model, which emphasizes on the model version control, the responsibility of open source licensing, and the commitment of continuous maintenance.

(6) Environment: The Environment class is used to describe the hardware and software dependencies and sustainability impacts of the model runtime environment, contains three subclasses: Hardware, Software, and Environmental Impact. Hardware describes the hardware platform required to run the model, such as the type of computing resources and memory configuration; Software characterizes the software dependencies required by the model, such as operating system and virtual environment information; and Environmental Impact describes the resource consumption and environmental impacts of the training and deployment of the model, such as the carbon emission estimation.

(7) Accountability: The Accountability class is used to describe the systematic management of legal compliance, ethical responsibility and potential risks during model development and deployment, and is an important metadata to ensure the credibility and auditability of AI models. This class contains three subclasses: Compliance, Risk, and Bias. Although Bias itself can be categorized under Risk, it is increasingly seen as a separate assessment and compliance topic, and is hereby separated into a subcategory to describe computational bias, data bias, institutional bias, and so on, that may exist in the model.

Object attributes reveal the association relationships between classes and are the basis for logical reasoning in ontologies. A total of 16 object attributes exist in the AI model ontology constructed in this study, and only the object attributes shown in Table 2 are listed in detail here.

Data attributes are able to represent static information and quantifiable features within class instances. Combining the above reused ontologies and specifications, the data attributes are additionally aligned according to the actual situation of the model. Limited to space, this paper only lists the data attributes of some entities here, and the sample attributes are shown in Table 3.

In this study, Protégé Ontology Modeling Editor is chosen to visualize the AI model ontology, and the conceptual classes, object attributes and data attributes of the AI model ontology are shown in Figure 2.

The rapid development of AI technologies has imposed increasingly stringent requirements on model interpretability and standardization. One of the core challenges currently facing the AI model ecosystem is the fragmentation of metadata standards and the lack of interoperability. This study systematically investigates this contradiction: on the one hand, the growing complexity of AI models necessitates transparent and structured management; on the other hand, the absence of unified standards hampers the efficiency of model development, sharing, and deployment. In response to the emerging challenges of interpretability, traceability, and governance brought about by the increasing complexity of AI models, this paper proposes and designs a unified metadata standard and ontological framework specifically tailored for AI models.

This study conceptualizes AI models as complex digital objects and characterizes them across their entire lifecycle. By integrating existing standards with ontological methodologies, it establishes a dynamic metadata framework that comprehensively covers the full lifecycle of AI models. This framework not only addresses fundamental attributes such as technical parameters and data characteristics, but also innovatively incorporates a range of social dimensions including task-driven functions, environmental dependencies, ethical risks, and human accountability. In doing so, it achieves an organic integration of technical specifications and societal values. This “techno-social” dual-perspective metadata system offers a new paradigm for the trustworthy development of AI models. It simultaneously meets the technical detail requirements of professional developers and responds to the transparency demands of regulatory authorities and the broader public, thereby providing methodological support for enhancing the transparency and trustworthiness of AI systems.