anyMeta Concepts

Often when people build a system they make a model of what they need at that moment and then build their system upon that model. Later, when their needs change or expand they have to go back and change their fundamental model, and thus the core foundations of the system. AnyMeta doesn't work like that: it was designed with the realization that models will change over the lives of systems, that Mediamatic is building many such systems, and that generic foundations can be developed. The only way to make these foundations universal is to skip any data modeling at the core technology level. In return for sacrificing a small amount of specificity we gain incredible flexibility and the ability to store just about anything. The strength of anyMeta is that it really emphasizes structured data storage and a future-proof flexible system. Once you've learned the API of one of these systems then you can use the APIs of all the others, since they all have the same basic structure and operate upon the same fundamental principles. anyMeta combines a quite usable social network environment and at the same time it's a highly structured Semantic Web-based information management system. Things Kinds Types Properties Edges Predicates Multilingualism Open-CI Authoritative and Non-Authoritative Things Permissions Modules Conclusion Things In seeking to make anyMeta universal we have to look at the world around us and get somewhat philosophical. We start with a simple assertion: any basic object is at root a Thing. For programmers, this is like how everything is an object is an object-oriented system. From the basic unit of a Thing we then attach metadata to them to describe the Thing, giving us the name anyMeta: everything is meta information! This metadata takes several forms, both as categorizations and as properties that independently describe the Thing, and as relationships with other Things. Kinds Kinds are mutually exclusive categorizations of Things and thus each Thing can only have one Kind: you're either a Keyword or a Person, you can't be both. But, as anyMeta is built upon generic foundations, the system allows me to change a Person into a Keyword with the click of a mouse. Because Kinds are mutually exclusive, it makes it a lot easier to reason about certain Things. Because Kinds are so basic they are often reused between anyMeta systems and most anyMeta systems use all the standard Kinds. That being said, you can naturally create more Kinds. Oh, and of course all Kinds are Things. The standard Kinds are: ARTEFACT ARTICLE ATTACHMENT INSTITUTION KEYWORD LANGUAGE LISTPUBLISH LOCATION NOTE PERSON ROLE SET TAG THEME TOPIC TYPE Types A Type is a simple categorization of a Thing, and a Thing can have as many Types as you like. Go wild with your Types, but don't try to make Types for things that are really relationships. Consider a Person: can he be a Father or a Son or an Author? These things are not Types because they do not exist independently: he is a Son in relation to the Person who is his Father. While a Thing may have several Types, Types generally only apply to Things with a Kind that is logical for the Type. In this way, we can consider a Type a sort of elaboration of a Kind. Below is a list of common Types organized by their associated Kind: ARTICLE REPORT HELP TEXT NEWS STORY ABOUTUS ARTEFACT IKCAM TICKET BOOK EVENT SIGN_UP_REQUIRED PUBLICATION PROJECT WEBSITE INSTITUTION PUBLISHER LISTPUBLISH MAILINGLIST BLOG LOCATION COUNTRY PERSON NOCONTACT SET MAILING GALLERY FORUM COMPETITION NAVIGATION Properties Properties are a generic way to add more stuff to Things in a structured way. Every Thing has some basic information like you might expect a news article to have: title, body, start and end dates, etc. Some things will only have a start date, not an end date: e.g. a photo. But even a photo might have both based upon the shutter time. Every Thing has standard GPS coordinates and publishing states (visibility and editing settings). If I know what kind of Thing a Thing is, I can add specific stuff. For instance, users have passwords. A user account is a Thing that is Kind Person. However, right now any Thing can be a User. In general it could be any Thing though right now it is almost always a Person Thing. Organizations are also Things and could also be a User if desired. It is convention that only Persons are Users and that you can only send a message or become friends with a Person. Several types of properties of Things are Things themselves: Type, Kind, Role. Some of these things are really part of the architecture of the system but we treat them as content so we can have a flexible system. Tags and Keywords are more 'free', and more part of the content or editorial architecture. Edges Practically anything can be any Thing and Things have very little inherent data. Thus, the meaning of a thing is primarily determined by its relationships, not its atoms or bits. That's primarily how you give structure to your data, by creating meaningful links between Things. These links in anyMeta are called Edges, and every Thing can be linked via an Edge. For instance, we can say that I (that is, the Peter Robinett Thing) current am in Amsterdam. However, I can also make Edges to indicate when I lived in Place Things like London, Paris, and Brussels. Edges can contain start and end dates for this reason. For some conventions, date of birth and date of death for example, they are stored in non semantic ways to allow for circumstances where not all information is known, for instance not knowing where I was born. Oh, and an Edge is not a Thing. This is a very important point to remember, as this means that when working with anyMeta you will work with two basic concepts, Things and Edges. Predicates While an Edge is a link between two Things, it's not very useful unless we say what type of link we've made. A Predicate is a property of an Edge which categorizes it, just like a Type categorizes a Thing. For this reason Predicates are very important, though I can make Edges without Predicates: it's not useful but it's possible, just like you can have a Thing without a Kind or a Type. While Edges are not Things, Predicates are, just like Types and Kinds are also Things. We can say that Edge::Predicate as Thing::Type. You can create multiple Edges with the same Predicate between the same two Things. To distinguish between them, then, the additional data directly on the Edge, like the start and end dates, becomes very important. For example, I might use the same KNOWS_OF Predicate to indicate my changing relationship with another person over time: they were friend from time X to Y, enemy from X1 to Y1, and finally friend again from X2 to Y2. Of course you would probably use different predicates to represent that changing relationship, but you get the idea. While Predicates describe a relationship between two Things in one direction, you can look at Edges from both the perspective of the subject and the object. This might seem confusing, so let's take a specific example. Let's say Peter knows John. Thus, there is a an Edge with Predicate KNOWS_OF with subject Thing Peter and object Thing John. It is easy, then, to ask who Peter knows, but anyMeta also lets you ask who knows John using a query with the same Predicate while indicating the John Thing is the object of the Edge, not the subject. This being said, because Predicates are usually named taking into consideration one direction of the relationship, sometimes there are related Predicates for Edges in either direction. For example, PARTICIPANT and PARTICIPANT_OF. The Predicate creator can decide between which Kinds of Things a Predicate is valid. This, of course, is not a structural limitation but a way to add more information through constraints, showing that Predicates function as a sort of content. Like with Kinds there are some Predicates that are common to all anyMeta systems and include ones like ACTOR, AUTHOR, LOCATED_IN, and TAKEN_AT. Every project will invariably create new Predicates, but Mediamatic constantly tries to weed them out, looking for similarities between projects and removing near duplicates so as to prevent a loss of common points of comparison across anyMeta systems. For example, 'I like it', 'I'm interested', and 'This is my favorite' on different anyMeta systems are all represented by the INTERESTED Predicate. Likewise the Predicate configuration (between which Kinds a Predicate is valid) varies per website. Here is a list of common Predicates: ABOUT ACCESS_GRANTED_BY ACCESS_GRANTED_TO ACTOR ATTENDED_BY AUTHOR BLOCKS BLOGPOSTING CHILD CLAIMED_BY COMMENT CONFIRMED_PARTICIPANT DOCUMENT EXTRA_CONTEXT FIGURE FRIEND HAS_TYPE ICON INTEREST KIN KNOWS KNOWS_OF LIVED LOCATED_IN LOOKS_AFTER MEMBER MODERATOR NARRATOR ORGANISED_BY PAID_PARTICIPANT PARTICIPANT PARTICIPANT_OF PRESENTED_AT PUBLISHED_BY REGISTERS RELATED RESOURCE SETMEMBER SETMOTHER SIBLING SPOUSE SUB_PROPERTY_OF SUBSCRIBER TAKEN_AT WORKS_FOR Multilingualism AnyMeta used a multilingual label file which is a very big translation table. All text for Things can be given in multiple languages, as can text for things like Predicates. This separation between an object and its text also allows standardization across anyMeta sites like the INTERESTED Predicates we mentioned previously while still giving site owners and editors the freedom to use the most appropriate text for their users. This is all handled behind the scenes and only becomes apparent to a user when they are an author creating versions of their text in multiple languages or are an API user requesting everything about a Thing and getting back versions of its text in all given languages as part of the response. Open-CI Open-CI is an initiative spear-headed by Mediamatic to make it easier for social sites to safely and securely share data while respecting privacy and only doing so when you ask them to. Naturally all anyMeta sites support Open-CI. With Open-CI you can log in on one anyMeta site with your account from another anyMeta site and link a photo on the site to an event on a third site, all securely. You can learn more at www.open-ci.nl. Resource URIs As an API user the key take-away from Open-CI is that API requests can return results from remote sites in the Open-CI network. Every result in the set, regardless of origin, will have a resource_uri, which is a fully-qualified URL of the item on its home site. anyMeta resource_uris are in the form http://the.site//thing_id. While these id URLs aren't part of the main anyMeta API, they can be used to get a variety of useful data and are detailed later in this document in the section called //thing_id. The URL can be used as identifiers in API requests and can be parsed to find the home system of the result. Every resource_uri is unique to an anyMeta server. When an entry is on the same anyMeta server as the one queried it will also contain a unique integer thing_id or event_id, so you will probably choose not to use resource_uris in your everyday API queries. Authoritative and Non-Authoritative Things Thing records can be copied from one anyMeta server to another. The original Thing will be marked as, and already was, authoritative. The new Thing on the second server will be marked as non-authoritative and will use the remote Thing's resource_uri as its own in order to link back to the original. The second anyMeta server will refuse to ever make any direct modifications on the new Thing and will instead mirror all changes to the remote authoritative Thing on the local non-authoritative one. It is not possible to have both the authoritative and non-authoritative Things be on the same anyMeta system, as their resource_uris would conflict. Permissions anyMeta has a permissions system that restricts certain actions in the system to certain users or groups of users. The first, or 'sysadmin', user has all permissions. By default a normal user has sufficient permissions to create new Things and to create Edges between Things they own: that is, to add content to the system. Permissions that standard users do not have include creating new types and edges and creating new users. A good rule of thumb is that normal users can create content while editors and other site managers and owners can create content and the context used in making the content. If you as an API user need more advanced permissions like the ability to create anyMeta users you will have to directly contact the site owner to request them. They can then grant authorization to use specific permissions via the anyMeta admin section. Related to permissions is the concept of publishing state. Even if a person would be able to see a Thing, for example if it is visible to everyone, they will not be able to see it if it is not marked as published. Many API methods default sensibly to the unpublished state and have to be explicitly marked as published, so this is an important potential gotcha. Modules AnyMeta has the concept of modules that can add additional features to a standard anyMeta install. Any API methods they provide tend to live under a namespace. The methods provided by the standard anyMeta system follow this convention and use the anymeta.api.method pattern. While most modules don't have much impact on the API, you should look out of the ThingDump module, as the ability to get a dump of everything about a Thing is very useful. This module is provided but not enabled by default, so contact your site administrator if you'd like to use it. Generally, though, you should be fine with the many API methods provided by the base system. Conclusion The challenge of anyMeta is to stimulate people to be extremely structured when inputting data into the system while still enjoying entering their data. All about creating links between structures to create structured meaning. Any anyMeta system uses all the Kinds because they're so basic. You need to look at what Types and Roles are used to understand the basic information architecture of the specific anyMeta system. All the rest is just content. Before you start an anyMeta site you start looking at your ontology/domain model/resource description framework, and every anyMeta project has an RDF (not completely stored in a machine readable format at the moment). Mediamatic makes sure to map what Kind and Types the project has and what types of Predicates exist. A blackboard exercise is the normal start of a Mediamatic project and focuses on exceptions, as this will reveal places where any new Types, Kinds, or Predicates are required. People familiar with the concepts of the Semantic Web will notice many similarities with anyMeta, as both are concerned with meaningful links between things. However, much of anyMeta predates and/or happened simultaneously with the Semantic Web, which is why there are some language differences. For example, a Role in anyMeta means the same thing as a Predicate in the jargon of the Semantic Web. Like with the Semantic Web anyMeta enables you to do advanced queries based around actual meaning across several levels of information, such as looking for anything involving a certain person at a certain location that has a certain tag.