US Patent App 20040158455: Methods and systems for managing entities in a computing device using semantic objects (Radar Networks)
Tuesday, July 1, 2008 at 3:00AM Title: Methods and systems for managing entities in a computing device using semantic objects
Patent App Number: US Patent Application 20040158455
Filed: November 20, 2003
Parent case: n/a
Inventor(s): Nova Spivack & Kristinn R. Thorisson
Assignee: Radar Network, Inc.
Prior art description: Categorizing the Internet's Serious Problems Φ
Abstract:
"A data construct referred to as a semcard is described. A semcard is a semantic (meaning-based) software object comprised of semantic meta-tags and meta-data that describes a target object or thing. A target object can be any type of digital or physical entity or identifier, or it can be tacit knowledge, such as ideas, concepts, processes or other data existing in a user's mind, provided that the user represents this knowledge in the semcard. A semcard also embodies information about its own structure--rules, history, state, policies and goals regarding automation, display, access permissions, sharing and other operations of the semcard and any optional target object, which may be contained within the semcard or be external to it. It can also represent a semantic link between two semcards, or between a semcard and its referent target. A collection of semcards represents a knowledge network; single semcards, as well as knowledge networks, can be browsed, shared, searched, disseminated, manipulated, displayed, organized, and stored as desired by the individual users of the semcard or knowledge network having a semcard management application or browsing software on their computational devices. Semcards can also represent relationships between users or, more generally, people and entities. A relationship semcard stores information relevant to a relationship and an invitation semcard is used to initiate a relationship. Semcards hold metadata, policies, and automation instructions about a relationship and, combined with a comparison mechanism, enable the enforcing application to control numerous aspects of the relationship thus represented, including which users can send the intended recipient data and what type of data the intended recipient has agreed to accept."
Blogger comments:
The present application claims priority under 35 USC Section 119 to Provisional Patent 60/427,550 filed on Nov. 20, 2002, titled Semantic Network Platform, Framework and Application as do the following two U.S. patent applications US Patent Application 20040220893 (Radar Networks), US Patent Application 20040230676 (Radar Networks). See also US Patent Application 20060004703.
For additional information, Nova Spivack very well tracks the claims and specifications set forth in the subject application in Nova Spivack: Making Sense of the Semantic Web, found elsewhere at this blog site. See also The Funding of the Emerging Semantic Web also found elsewhere at this blog site.
Independent claims (as numbered):
1. A semantic object representing an entity or tacit information, the semantic object comprising: semantic tags describing attributes of the entity or tacit information, including relationships to other semantic objects, to physical or software objects, or to information existing in the mind of a human being; and rules embodying goals, automation and other policies regarding how the semantic object interacts with, is manipulated by, and is displayed to human beings and automatic processes; wherein a semantic object can be searched using semantic tags and meta-data contained in the semantic object, the meta-data being paired with the semantic tags and wherein the semantic tags can be extended by an owner of the semantic object and shared over a network.
2. A method of managing a relationship between a first semantic object and a second semantic object, wherein the relationship is represented by a third semantic object, the method comprising: posting an invitation semantic object; accepting the invitation semantic object; providing the second semantic object with a first set of policies of the first semantic object and providing the first semantic object with a second set of policies of the second semantic object, wherein the policies can prevent data from being received at a semantic object by preventing data from originating at a source; encapsulating data about the relationship in the third semantic object; and enabling modification of either set of policies during the relationship.
Key Drawing(s):
"A semcard can be thought of as a form with fields or slots, and has two incarnations, template and instance, which correspond roughly to the object-oriented programming concepts of object template and object instance.
As shown in further detail in FIGS. 1 and 2, [below,] each semcard has numerous semantic dimensions, also referred to as meta-tags in the semcard template. For example, for a semcard representing a material object, a semantic dimension (meta-tag) can be "color", which contains a particular value (meta-data), and restrictions on what kind that value may be. (Semcards are also used to represent the semcard templates themselves.) To fill out a semcard, an instance is made of a semcard's template, and selected slots of the instance are filled with values. Each semcard instance, its semantic dimensions, and their values for each semcard, can be stored on a computer readable medium as an XML (eXtensible Markup Language) object, using the RDF (Resource Description Framework) format, any binary storage format, or other chosen format. Semcard templates can be created by designers, who hand-pick the meta-tags that define the semcard's referent target. Semcards can also be created dynamically and automatically through automated selection and organization of meta-tags from a pool of metatags; the selection of meta-tags and their organization in the semcard being driven by heuristic rules, e.g. by the meta-tags' popularity with a group of semcard users and authors.
[Original image modified for size and/or readability] Referring to FIG. 1, a semcard 1 contains rows, called slots, 2 for storing metatag-metadata pairs, tags on the left side 3, metadata on the right-hand side 4. A semcard 2 with example tags 6, 8, 10, 12, 14, 16 and example values for each tag 7, 9, 11, 13, 15. Slot 17 would hold a reference to a link semcard, as explained further below and in FIG. 6. In a preferred embodiment of the present invention, semcards are defined in XML that can be easily transformed to/from other data formats, including other XML formats, HTML, RSS, RDF, SHOE, DAML+OIL and OWL, as well as other application specific data formats. For the purposes of the present invention, the size and complexity of a semcard can vary. A collection of semcards linked together is referred to as a knowledge network. In a preferred embodiment, people can access and manipulate individual semcards, and knowledge networks, via desktop tools, as well as with standard Web browsers.
[Original image modified for size and/or readability] Although the amount of metadata in a single semcard can be very small or extremely large, a semcard is intended to be of a convenient size from a cognitive standpoint, so as not to overload its user with too much information. For example, a semcard describing an automobile would have the typical "common sense" data about its color, type, seating, engine power, etc.; if more information was desired to be represented about the car's engine, a separate semcard could be created for this purpose, and linked to from the automobile semcard. This way the relationship between single semcards and collections of semcards--or knowledge networks--is kept at a cognitively manageble ratio.
Reader Comments