DOCSLIB.ORG

XML Metadata Standards and Topic Maps Outline

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

XML Metadata Standards and Topic Maps Erik Wilde 16.7.2001 XML Metadata Standards and Topic Maps 1 Outline what is XML? z a syntax (not a data model!) what is the data model behind XML? z XML Information Set (basically, trees...) what can be described with XML? z describing the content syntactically (schemas) z describing the content abstractly (metadata) XML metadata is outside of XML documents ISO Topic Maps z a "schema language" for meta data 16.7.2001 XML Metadata Standards and Topic Maps 2 1 Extensible Markup Language standardized by the W3C in February 1998 a subset (aka profile) of SGML (ISO 8879) coming from a document world z data are documents defined in syntax z no abstract data model problems in many real-world scenarios z how to compare XML documents z attribute order, white space, namespace prefixes, ... z how to search for data within documents z query languages operate on abstract data models z often data are not documents 16.7.2001 XML Metadata Standards and Topic Maps 3 Why XML at all? because it's simple z easily understandable, human-readable because of the available tools z it's easy to find (free) XML software because of improved interoperability z all others do it! z easy to interface with other XML applications because it's versatile z the data model behind XML is very versatile 16.7.2001 XML Metadata Standards and Topic Maps 4 2 XML Information Set several XML applications need a data model z style sheets for XML (CSS, XSL) z interfaces to programming languages (DOM) z XML transformation languages (XSLT) z XML fragment identifiers (XPointer) z XML query languages (XQuery) XML does not have a real data model z implicitly defined, but not authoritatively XML Information Set (XML Infoset) z describes a set of information items z each XML document is a set of such items 16.7.2001 XML Metadata Standards and Topic Maps 5 XML Infoset Essentials only Namespace-compliant XML allowed! so what's in the Infoset? z elements z attributes z Namespace declarations and prefixes z comments z processing instructions and what's not in the Infoset? z whitespace within element tags z the order of attributes within element tags z any information about the DTD 16.7.2001 XML Metadata Standards and Topic Maps 6 3 XML Schema Languages XML represents structured Information z XML Infoset defines the data model (trees) z XML 1.0 defines a character-based syntax XML 1.0 also defines DTDs z element types and their content models z attributes and their data types every XML application has to support DTDs z the only globally accepted schema language z almost 20 years old z many drawbacks for non-document scenarios 16.7.2001 XML Metadata Standards and Topic Maps 7 XML Schema developed because of user demand z B2B scenarios need better data types z data modeling needs better structuring XML Schema W3C standard since 5/2001 z implementations available z rapid adoption is very likely Part I defines structuring mechanisms z element types may be derived from each other Part II defines a data type vocabulary z a set of application-oriented simple types 16.7.2001 XML Metadata Standards and Topic Maps 8 4 Schemas and Metadata XML resources may contain any type of data z documents (as originally intended by SGML) z order forms (as is common in B2B scenarios) z generic things such as RPC requests and responses z SOAP and XML RPC are two popular variants z or even information about other resources XML metadata describes data resources z not necessarily XML data (eg, image descriptions) z not necessarily attached to the resources z making comments on other people's resources z metadata is also data (ie, structured information) z XML metadata needs schema definitions 16.7.2001 XML Metadata Standards and Topic Maps 9 XMLizing the World... should everything be XML? z structured data would be an appropriate target z but what about GIF, JPEG, MPEG, ... ? everything should be described using XML z descriptions of resources are metadata z metadata is structured data z metadata should be in XML so there must be an XML metadata standard z TimBL's favorite: Resource Description Framework z coming from ISO standardization: Topic Maps 16.7.2001 XML Metadata Standards and Topic Maps 10 5 Resource Description Framework RDF starts with a data model z and defines an XML syntax for representation everything in RDF can be represented by a graph with nodes and arcs z each node is a resource z each arc represents a property z properties and resources are named with URIs describes the whole Web and beyond z anything which can be named with a URI z which is almost anything (phone, tv-channels, ...) RDF graphs describe logical assertions 16.7.2001 XML Metadata Standards and Topic Maps 11 RDF Metadata RessourceRessource RDFRDF RDFRDF SchemaSchema DescriptionDescription (Ontology)(Ontology) RDFRDF SchemaSchema && SyntaxSyntax 16.7.2001 XML Metadata Standards and Topic Maps 12 6 RDF-based Email Description 16.7.2001 XML Metadata Standards and Topic Maps 13 But ... what is it good for? ask questions about the email z who sent me mail on a particular topic? z get me all the mail from Fred Smith z who where the people who I mailed with on Friday? join the email graphs with other ones z address books z home pages z browser history z organizational affiliations 16.7.2001 XML Metadata Standards and Topic Maps 14 7 Topic Maps Topics are "things of interest" z loosely defined, widely usable z each Topic has name(s) and/or occurrence(s) z Topics have "topic types" (which are Topics...) Associations are used to connect Topics z the have an "association type" (which is a Topic...) z Topics references in Associations have an "association role type" (which are Topics...) Topic Occurrences point to resources z anything addressable by a name (URI) z described by an "occurrence role type" (a Topic...) 16.7.2001 XML Metadata Standards and Topic Maps 15 A Simple Topic Map 16.7.2001 XML Metadata Standards and Topic Maps 16 8 The Whole Picture 16.7.2001 XML Metadata Standards and Topic Maps 17 Topic Map View (I) 16.7.2001 XML Metadata Standards and Topic Maps 18 9 Topic Map View (II) 16.7.2001 XML Metadata Standards and Topic Maps 19 Topic Map View (III) 16.7.2001 XML Metadata Standards and Topic Maps 20 10 Comparison RDF Topic Maps standardized by W3C standardized by ISO explicit data model defined by syntax properties have data types associations aren't constrained inherently distributed centralized separates schema from eveything (almost...) is a topic, instance (resource description) there are no types 16.7.2001 XML Metadata Standards and Topic Maps 21 What is missing? for Topic Maps only z a clean way to separate schemas and instances z a constraint language for topic associations z a way to distribute Topic Maps for RDF only z a unified data model with XML Schema for both approaches z tools for creating and managing metadata z a query language for actually using metadata z support from a wide range of vendors & users z an approach for achieving vocabulary consensus z smart ways to handle distribution 16.7.2001 XML Metadata Standards and Topic Maps 22 11 XLinkbase System Architecture HTML X.500 CMS HTTP Server Browser LDAP EJB Pool EJB EJB Search XQuery HTTP Engine Server XML EJB EJB XLink XSLT EJB Browser JDBC EJB EJB EJB Servlet Engine XLinkbase RDBMS J2EE (EJB/JMS/JTS) Servlet Client exchanging XML messages XLinkbase Server HTTP Server 16.7.2001 XML Metadata Standards and Topic Maps 23 XLinkbase Status where the implementation is going z currently concentrating on EJB environment z hard to keep up with commercial engines z case study with simpler model & implementation z case study for generating DHTML links where the concept is going z proof of concept with the case study z 1 or 2 DAs dealing with Topic Map distribution z looking into data model improvements z constraint language for associations z schema/instance separation or separability 16.7.2001 XML Metadata Standards and Topic Maps 24 12.
Recommended publications
  • Lyon-Nist241assmoct9.Pdf

    Lyon-Nist241assmoct9.Pdf

    NIST Special Publication 500-241 Information Technology: A Quick-Reference List of Organizations and Standards for Digital Rights Management Gordon E. Lyon NIST Special Publication 500-241 Information Technology: A Quick-Reference List of Organizations and Standards for Digital Rights Management Gordon E. Lyon Convergent Information Systems Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8951 October 2002 U.S. Department of Commerce Donald L. Evans, Secretary Technology Administration Phillip J. Bond, Under Secretary of Commerce for Technology National Institute of Standards and Technology Arden L. Bement, Jr., Director Reports on Information Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) stimulates U.S. economic growth and industrial competitiveness through technical leadership and collaborative research in critical infrastructure technology, including tests, test methods, reference data, and forward-looking standards, to advance the development and productive use of information technology. To overcome barriers to usability, scalability, interoperability, and security in information systems and networks, ITL programs focus on a broad range of networking, security, and advanced information technologies, as well as the mathematical, statistical, and computational sciences. This Special Publication 500-series reports on ITL’s research in tests and test methods for information technology, and its collaborative activities with industry, government, and academic organizations. Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.
  • Metadata and GIS

    Metadata and GIS

    Metadata and GIS ® An ESRI White Paper • October 2002 ESRI 380 New York St., Redlands, CA 92373-8100, USA • TEL 909-793-2853 • FAX 909-793-5953 • E-MAIL [email protected] • WEB www.esri.com Copyright © 2002 ESRI All rights reserved. Printed in the United States of America. The information contained in this document is the exclusive property of ESRI. This work is protected under United States copyright law and other international copyright treaties and conventions. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system, except as expressly permitted in writing by ESRI. All requests should be sent to Attention: Contracts Manager, ESRI, 380 New York Street, Redlands, CA 92373-8100, USA. The information contained in this document is subject to change without notice. U.S. GOVERNMENT RESTRICTED/LIMITED RIGHTS Any software, documentation, and/or data delivered hereunder is subject to the terms of the License Agreement. In no event shall the U.S. Government acquire greater than RESTRICTED/LIMITED RIGHTS. At a minimum, use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in FAR §52.227-14 Alternates I, II, and III (JUN 1987); FAR §52.227-19 (JUN 1987) and/or FAR §12.211/12.212 (Commercial Technical Data/Computer Software); and DFARS §252.227-7015 (NOV 1995) (Technical Data) and/or DFARS §227.7202 (Computer Software), as applicable. Contractor/Manufacturer is ESRI, 380 New York Street, Redlands, CA 92373- 8100, USA.
  • Creating Permissionless Blockchains of Metadata Records Dejah Rubel

    Creating Permissionless Blockchains of Metadata Records Dejah Rubel

    Articles No Need to Ask: Creating Permissionless Blockchains of Metadata Records Dejah Rubel ABSTRACT This article will describe how permissionless metadata blockchains could be created to overcome two significant limitations in current cataloging practices: centralization and a lack of traceability. The process would start by creating public and private keys, which could be managed using digital wallet software. After creating a genesis block, nodes would submit either a new record or modifications to a single record for validation. Validation would rely on a Federated Byzantine Agreement consensus algorithm because it offers the most flexibility for institutions to select authoritative peers. Only the top tier nodes would be required to store a copy of the entire blockchain thereby allowing other institutions to decide whether they prefer to use the abridged version or the full version. INTRODUCTION Several libraries and library vendors are investigating how blockchain could improve activities such as scholarly publishing, content dissemination, and copyright enforcement. A few organizations, such as Katalysis, are creating prototypes or alpha versions of blockchain platforms and products.1 Although there has been some discussion about using blockchains for metadata creation and management, only one company appears to be designing such a product. Therefore, this article will describe how permissionless blockchains of metadata records could be created, managed, and stored to overcome current challenges with metadata creation and management. LIMITATIONS OF CURRENT PRACTICES Metadata standards, processes, and systems are changing to meet twenty-first century information needs and expectations. There are two significant limitations, however, to our current metadata creation and modification practices that have not been addressed: centralization and traceability.
  • Approved DITA 2.0 Proposals

    Approved DITA 2.0 Proposals

    DITA Technical Committee DITA 2.0 proposals DITA TC work product Page 1 of 189 Table of contents 1 Overview....................................................................................................................................................3 2 DITA 2.0: Stage two proposals.................................................................................................................. 3 2.1 Stage two: #08 <include> element.................................................................................................... 3 2.2 Stage two: #15 Relax specialization rules......................................................................................... 7 2.3 Stage two: #17 Make @outputclass universal...................................................................................9 2.4 Stage two: #18 Make audience, platform, product, otherprops into specializations........................12 2.5 Stage two: #27 Multimedia domain..................................................................................................16 2.6 Stage two: #29 Update bookmap.................................................................................................... 20 2.7 Stage two: #36 Remove deprecated elements and attributes.........................................................23 2.8 Stage two: #46: Remove @xtrf and @xtrc...................................................................................... 31 2.9 Stage 2: #73 Remove delayed conref domain.................................................................................36
  • A 3-Tier Application for Topic Map Technology

    A 3-Tier Application for Topic Map Technology

    Proceedings of the 6th WSEAS International Conference on Applied Computer Science, Tenerife, Canary Islands, Spain, December 16-18, 2006 356 A 3-tier Application for Topic Map Technology A. PAPASTERGIOU, G. GRAMMATIKOPOULOS*, A. HATZIGAIDAS, G. TRYFON Department of Electronics, (*) Department of Esthetics Alexander Technological Educational Institute of Thessaloniki, EPEAEK II Sindos, 57400, Thessaloniki, Macedonia, GREECE Abstract: In the context of this paper the design and construction of a 3-tier application system for topic map technology is presented in detail. The proposed system employs Enterprise Topic Map Server (ETMS) that manages topic maps (TM) and establishes communication with client applications and persistent database. Yellow Web Services have been customized in order to achieve communication issues and exchange of TM. A client application is addressed to TM developers for editing and visualization of TM. Furthermore, the definition of TM Schema as well as the possibility to process rules and queries are supported. Another key aspect of the present paper is to analyze how different technologies utilized to formulate such a system. Key-words: Topic map, Server, Web services, Client, 3-tier, TM schema, Retrieval 1 Introduction definition of TM Schema as well as the possibility to The Topic Map model describes a mechanism for process rules and queries are also supported. In the representing knowledge about the structure of next sections the overall architecture of the proposed information and organizing it into topics [1,19]. Topics system as well as technologies that are implied in have occurrences and associations that define order to build the system are represented in details. relationships between the topics, creating thus a semantic network over the information [8,18].
  • Mapping Topic Maps to Common Logic

    Mapping Topic Maps to Common Logic

    MAPPING TOPIC MAPS TO COMMON LOGIC Tamas´ DEMIAN´ Advisor: Andras´ PATARICZA I. Introduction This work is a case study for the mapping of a particular formal language (Topic Map[1] (TM)) to Common Logic[2] (CL). CL was intended to be a uniform platform ensuring a seamless syntactic and semantic integration of knowledge represented in different formal languages. CL is based on first-order logic (FOL) with a precise model-theoretic semantic. The exact target language is Common Logic Interchange Format (CLIF), the most common dialect of CL. Both CL and TM are ISO standards and their metamodels are included in the Object Definition Metamodel[3] (ODM). ODM was intended to serve as foundation of Model Driven Architecture (MDA) offering formal basis for representation, management, interoperability, and semantics. The paper aims at the evaluation of the use of CL as a fusion platform on the example of TM. II. The Topic Maps TM is a technology for modelling knowledge and connecting this structured knowledge to relevant information sources. A central operation in TMs is merging, aiming at the elimination of redundant TM constructs. TopicMapConstruct is the top-level abstract class in the TM metamodel (Fig. 1). The later detailed ReifiableConstruct, TypeAble and ScopeAble classes are also abstract. The remaining classes are pairwise disjoint. Figure 1: The class hierarchy and the relation and attribute names of the TM metamodel. TopicMap is a set of topics and associations. Topic is a symbol used within a TM to represent exactly one subject, in order to allow statements to be made about that subject.
  • Studying Social Tagging and Folksonomy: a Review and Framework

    Studying Social Tagging and Folksonomy: a Review and Framework

    Studying Social Tagging and Folksonomy: A Review and Framework Item Type Journal Article (On-line/Unpaginated) Authors Trant, Jennifer Citation Studying Social Tagging and Folksonomy: A Review and Framework 2009-01, 10(1) Journal of Digital Information Journal Journal of Digital Information Download date 02/10/2021 03:25:18 Link to Item http://hdl.handle.net/10150/105375 Trant, Jennifer (2009) Studying Social Tagging and Folksonomy: A Review and Framework. Journal of Digital Information 10(1). Studying Social Tagging and Folksonomy: A Review and Framework J. Trant, University of Toronto / Archives & Museum Informatics 158 Lee Ave, Toronto, ON Canada M4E 2P3 jtrant [at] archimuse.com Abstract This paper reviews research into social tagging and folksonomy (as reflected in about 180 sources published through December 2007). Methods of researching the contribution of social tagging and folksonomy are described, and outstanding research questions are presented. This is a new area of research, where theoretical perspectives and relevant research methods are only now being defined. This paper provides a framework for the study of folksonomy, tagging and social tagging systems. Three broad approaches are identified, focusing first, on the folksonomy itself (and the role of tags in indexing and retrieval); secondly, on tagging (and the behaviour of users); and thirdly, on the nature of social tagging systems (as socio-technical frameworks). Keywords: Social tagging, folksonomy, tagging, literature review, research review 1. Introduction User-generated keywords – tags – have been suggested as a lightweight way of enhancing descriptions of on-line information resources, and improving their access through broader indexing. “Social Tagging” refers to the practice of publicly labeling or categorizing resources in a shared, on-line environment.
  • Metadata Creation Practices in Digital Repositories and Collections

    Metadata Creation Practices in Digital Repositories and Collections

    Metadata Creation Practices in Digital Repositories and Collections: Schemata, Jung-ran Park and Selection Criteria, and Interoperability Yuji Tosaka This study explores the current state of metadata-creation development of such a mediation mechanism calls for practices across digital repositories and collections by an empirical assessment of various issues surrounding metadata-creation practices. using data collected from a nationwide survey of mostly The critical issues concerning metadata practices cataloging and metadata professionals. Results show across distributed digital collections have been rela- that MARC, AACR2, and LCSH are the most widely tively unexplored. While examining learning objects and used metadata schema, content standard, and subject- e-prints communities of practice, Barton, Currier, and Hey point out the lack of formal investigation of the metadata- controlled vocabulary, respectively. Dublin Core (DC) is creation process.2 As will be discussed in the following the second most widely used metadata schema, followed section, some researchers have begun to assess the current by EAD, MODS, VRA, and TEI. Qualified DC’s wider state of descriptive practices, metadata schemata, and use vis-à-vis Unqualified DC (40.6 percent versus 25.4 content standards. However, the literature has not yet developed to a point where it affords a comprehensive percent) is noteworthy. The leading criteria in selecting picture. Given the propagation of metadata projects, it is metadata and controlled-vocabulary schemata are collec- important to continue to track changes in metadata-cre- tion-specific considerations, such as the types of resources, ation practices while they are still in constant flux. Such efforts are essential for adding new perspectives to digital nature of the collection, and needs of primary users and library research and practices in an environment where communities.
  • Geotagging Photos to Share Field Trips with the World During the Past Few

    Geotagging Photos to Share Field Trips with the World During the Past Few

    Geotagging photos to share field trips with the world During the past few years, numerous new online tools for collaboration and community building have emerged, providing web-users with a tremendous capability to connect with and share a variety of resources. Coupled with this new technology is the ability to ‘geo-tag’ photos, i.e. give a digital photo a unique spatial location anywhere on the surface of the earth. More precisely geo-tagging is the process of adding geo-spatial identification or ‘metadata’ to various media such as websites, RSS feeds, or images. This data usually consists of latitude and longitude coordinates, though it can also include altitude and place names as well. Therefore adding geo-tags to photographs means adding details as to where as well as when they were taken. Geo-tagging didn’t really used to be an easy thing to do, but now even adding GPS data to Google Earth is fairly straightforward. The basics Creating geo-tagged images is quite straightforward and there are various types of software or websites that will help you ‘tag’ the photos (this is discussed later in the article). In essence, all you need to do is select a photo or group of photos, choose the "Place on map" command (or similar). Most programs will then prompt for an address or postcode. Alternatively a GPS device can be used to store ‘way points’ which represent coordinates of where images were taken. Some of the newest phones (Nokia N96 and i- Phone for instance) have automatic geo-tagging capabilities. These devices automatically add latitude and longitude metadata to the existing EXIF file which is already holds information about the picture such as camera, date, aperture settings etc.
  • Semantic Mapping in ROS XAVIER GALLART DEL BURGO

    Semantic Mapping in ROS XAVIER GALLART DEL BURGO

    Semantic Mapping in ROS XAVIER GALLART DEL BURGO Master’s Thesis at CVAP/CAS, The Royal Institute of Technology, Stockholm, Sweden Supervisor: Dr. Andrzej Pronobis Examiner: Prof. Danica Kragic August, 2013 Abstract In the last few years robots are becoming more popular in our daily lives. We can see them guiding people in museums, helping surgeons in hospitals and autonomously cleaning houses. With the aim of enabling robots to cooperate with humans and to perform human-like tasks we need to provide them with the capability of understanding human envi- ronments and representing the extracted knowledge in such a way that humans can interpret. Semantic mapping can be defined as the process of building a representation of the environment, incorporating semantic knowledge obtained from sensory information. Semantic properties can be extracted from various sources such as objects, topology of the envi- ronment, size and shape of rooms and room appearance. This thesis proposes an implementation of semantic mapping for mo- bile robots which is integrated in a framework called Robot Operat- ing System (ROS). The system extracts spatial properties like rooms, objects and topological information and combines them with common- sense knowledge into a probabilistic framework which is capable of in- ferring room categories. The system is tested in simulations and in real-world scenarios and the results show how the system explores an unknown environment, creates an accurate map, detects objects, infers room categories and represents the results in a map where each room is labelled according to its functionality. Acknowledgements First and foremost, I would like to express my gratitude to my super- visor, Andrzej Pronobis, for giving me the opportunity to develop my thesis in one of my passions, the robots.
  • Topic Map Aided Publishing

    Topic Map Aided Publishing

    A Case Study of Assembly Media Archive Topic Map Aided Publishing Grip Studios Interactive, Aki Kivelä 2.9.2004 Assembly’04 Media Archive WWW publishing platform. Publishes images, videos and related metadata real-time. Integrated to Assembly’s [1] publishing environment. Uses Topic Maps [2] to store knowledge. Supports heterogeneous data sources. Short development time . Short life span. [1] Assembly’04 http://www.assembly.org/ [2] Steve Pepper. The TAO of Topic Maps, finding the way in the age of infoglut http://www.gca.org/papers/xmleurope2000/pdf/s11-01.pdf 2 Publishing Environment of the Assembly Media Archive video production team VideoStore Media Archive Elaine topicmap image production team clients 3 Video Production Process Process and services were designed FTP by Assembly’04 crew. HTTP SERVER HTTP video production team VideoStore Media Archive Elaine topicmap image production team clients HTTP, WWW FORM HTTP, XML 4 Image Production Process Uploading images and metadata to Media Archive video production team VideoStore Media Archive Elaine topicmap image production team clients JPEG, XTM (TOPIC MAPS) TCP/IP, ADMINISTRATION APPLICATION 5 Merging Elaine Media Archive video & image knowledge Merging Topic Maps from heterogeneous sources Video XSL [3] Video XTM XML Topic Map XTM MERGE [4] Merged XTM Topic Map Image Image XTM XTM Topic Map Topic Map Administration Ontology Application Media Archive XTM Topic Map [3] XSL Style Sheets http://www.w3c.org/Style/XSL/ [4] Merging Topic Maps http://www.topicmaps.org/xtm/index.html#desc-merging 6 Topic Map Topic Maps Map of information resources Collection of Topics, Associations between topics and related information resources (Occurrences) Steve Pepper.
  • Published Subjects: Introduction and Basic Requirements

    Published Subjects: Introduction and Basic Requirements

    Published Subjects: Introduction and Basic Requirements OASIS Published Subjects Technical Committee Recommendation, 2003-06-24 Document identifier: pubsubj-pt1-1.01-cs Location: http://www.oasis-open.org/committees/documents.php?wg_abbrev=tm- pubsubj Editor: Steve Pepper <[email protected]> Contributors: Bernard Vatant (TC Chair), Suellen Stringer-Hye (TC Secretary), James David Mason (TC Liaison with ISO/IEC JTC1/SC34), Thomas Bandholtz, Vivian Bliss, Patrick Durusau, Peter Flynn, Eric Freese, Lars Marius Garshol, Kim Sung Hyuk, Motomu Naito, Eamonn Neylon, Mary Nishikawa, Michael Priestley, H. Holger Rath, Don Smith Abstract: This document provides an introduction to Published Subjects and basic requirements and recommendations for publishers of Published Subjects. Status: Committee Specification Copyright © 2003 The Organization for the Advancement of Structured Information Standards [OASIS] Table of Contents 1. Introduction 2. A Gentle Introduction to Published Subjects 2.1 Subjects and Topics 2.2 The Identification of Subjects 2.3 The Addressability of Subjects 2.4 Subject Indicators and Subject Identifiers 2.4.1 Subject Identification for Humans: Subject Indicators 2.4.2 Subject Identification for Computers: Subject Identifiers 2.4.3 Distinguishing between Subject Addresses and Subject Identifiers 2.4.4 Example: Identifying the Subject "Apple" 2.5 Published Subjects 2.5.1 Shortcomings of the above scenario 2.5.2 Publishers in the loop 2.5.3 Example: A Published Subject for "Apple" 2.6 The Adoption of PSIs 3. Requirements and Recommendations for PSIs 3.1 Requirements for PSIs 3.1.1 A PSID must be a URI 3.1.2 A PSID must resolve to a PSI 3.1.3 A PSI must explicitly state its PSID 3.2 Recommendations for PSIs 3.2.1 A PSI should provide human-readable metadata 3.2.2 A PSI may provide machine-readable metadata 3.2.3 Human-readable and machine-readable metadata should be consistent but need not be equivalent 3.2.4 A PSI should indicate its intended use as a PSI 3.2.5 A PSI should identify its publisher 4.