New Feature: Object History

N Levels now tracks history for each object. This history includes the following information:

• when the object was created (along with the properties that were set)
• when the object was modified (along with the modified properties)
• when a relationship is modified, i.e. a target object is added or removed
• when the object is added or removed as the target of a relationship

Each object has its own history page (see this example). You can "scope" the history that is displayed to the past hour, day, week, month, year, or the object's complete lifetime.

Note that for property-related history items (e.g. object creation or modification), the object owner can view the property values that were set (if they are logged into the site). However, these values are not visible to other users - the history simply lists which properties were modified.

There is an associated RSS history feed for each object. This feed can also be scoped as described above, and includes the same information that is displayed in the history page. This makes it easy for someone to keep up-to-date on the changes for a given object, by using any standard RSS reader (see screenshot of a history feed as viewed in the RssReader application).

Currently we generate an unique RSS history feed for each object. In the future, we plan to enable users to create customized RSS feeds for a collection of objects - e.g. all objects which match a specified search criteria, or all objects of a certain type owned by a specific user. Feedback and suggestions on how we can improve the usefulness of this feature would be greatly appreciated!

New Feature: Control how object properties are displayed

One of the recent features we've added to N Levels is the ability to control how object properties are ordered (from a display perspective) in the object "create" and "edit" pages, as well as object widgets.

When you create a new object type you select the property types that it includes. In addition to specifying which of these property types are mandatory, you can also control the order in which they are displayed, as shown in this screenshot.

The ability to order how properties are displayed is useful especially in situations where you have a large number of properties, or where the properties are related and have a meaningful ordering. For example, the property types for a physical location have a standard canonical ordering of address / city / state / postal code / country.

Something to be aware of as you create your own object types...

Using N Levels to track hotel wi-fi speeds

During the summer I came across a blog posting by Jeff Jarvis that proposed a tagging convention for reporting hotel wi-fi speeds. The idea is that people would record hotel wi-fi speeds in their blog entries, and then tag these entries so that others could easily search for and find them.

I thought this was a great idea, and also a great example of the type of problem -- capturing a related set of information authored in a distributed fashion -- that N Levels would be well suited to address and potentially provide a richer, more flexible solution than what can be enabled by tagging blog entries.

Now that N Levels is up-and-running, I thought I'd lay out how it could be used for this scenario and hopefully get folks to try it out.

First I defined an object type for a "hotel wifi report". Such an object would be created to record your hotel wi-fi experience including information about the hotel, upload / download speeds, connection type, pricing plan, and any comments you have. You can view the schema definition here. Creating a new hotel wifi report is straightforward - simply enter the information requested (note you will need to have a N Levels account to create a report). To illustrate this, I've created a handful of "fake" reports which you can view here.

Notice that the hotel wifi reports all follow a naming convention which is described in the object type definition. Because all object names in N Levels must be unique, having a convention to name objects of a given type will reduce the chance of naming collisions, as well as provide meaningful information through the object name.

So how would these "hotel wifi report" objects be used? For starters, you could add a widget for one into a blog posting - say one that describes your trip. The widget would look something like:

More interestingly, as folks create more hotel wifi reports, you can use the search functionality of N Levels to find wifi reports that match a specified criteria. Because the information is captured in a structured schema, you can search in a richer way than is possible via a tag-based approach. You could search for all wifi reports for a given hotel. Or you could search for all wifi reports for a given city where the upload and download speeds are greater than a given threshold. To illustrate this, here is a search widget that returns the wifi reports for RandomCity, NY, taken since July 2007, where the download speed is greater than 2000 kbps (see a screenshot of the corresponding search query).

(Note that this widget is dynamic - as new hotels are added which match the search criteria, the widget will display them.)

You may have noticed that the sample hotel wifi reports contain a relationship named "associated hotel (wifi report)". This relationship can point to a "hotel" object that represents the hotel in the wifi report. If the hotel object has already been created, then the user can select it; otherwise they can create a new hotel object and add it to the relationship. The hotel wifi report widget above shows a link to this page which allows someone to manage the relationship. (Ideally someone would pre-populate a complete listing of all hotels worldwide. In the meantime, we'll have to take an organic approach and rely on folks to create hotel objects and ensure the information is accurate.)

Through population of this relationship, it becomes possible to create a richer network of information. Now you can go to a Hotel object and view all of the wifi reports for it, as shown in the sample hotel widget below.

Linking the hotel wifi reports to the associated hotel object adds value, but is not mandatory - as long as the wifi reports contain enough information so people can search by hotel name, location, etc.

In summary, N Levels lets you define and create a rich collection of structured data - the information you capture and what you do with it is up to you. Tracking hotel wifi information is a useful scenario, but also just one of many possible. I'd like to ask people to give this a try - it's pretty simple and hopefully we can build a valuable collection of reports over time.

• Create new hotel wifi report.
• Search existing hotel wifi reports.
• Help us populate our hotel listing by creating a new hotel object.

If you have feedback on the hotel wifi report or hotel schemas, or feedback in general, we'd love to hear it - send mail to nleveler@nlevels.com or post a comment on this blog.

N Levels and Information Networks

The goal of N Levels is to enable users to create their own "information networks" that overlay and complement today's web page and hyperlink structure.

By information network, we mean a set of objects that are connected by relationships, forming a directed graph.

An object is a collection of properties which represents "something" - it could be a physical entity, animal, person, concept, idea, or absolutely anything. A relationship is a label that defines how two objects are related to each other - for example parent-child, location, containment, etc. An object and its possible relationships is defined by its schema, or "object type". By having well-defined schema, it becomes easy for humans and software to traverse, consume, and extend an information network.

We believe information networks have the potential to drive the web scenarios of the future. While the web obviously contains an abundance of information, that information is primarily (1) represented as text on web pages, or (2) stored within databases for particular sites. In the first case, the information is not structured and hence hard for software to consume or connect to other information. In the second case, the information is structured but is generally only available within the context of a given web site. And even if that information is made available through a web service API, generally the schema used will be specific to that site - which makes it difficult to relate information from multiple sites.

The utility and benefit of structured networks of data is illustrated by the growth of social networking sites, which effectively implement a particular flavor of information network - the objects being things like people, schools, and companies, and relationships being things like "friend", "worked together", and "currently attends". As the fundamental value of a social network comes from these objects and relationships (aka the "social graph"), we would like to allow people to access, modify, and extend this information directly and in a decentralized fashion.

Looking to the future, the information network and "semantic web" would seem to be closely related. With N Levels, however, we have not attempted to have the level of richness and formalism of semantic web standards such as RDF and OWL. At least initially, we've opted for a more "loose" and simplistic approach to defining the schema. Over time we may adopt some of these standards if we think it will increase the usefulness of the service.

As we set about designing and building N Levels, we had the following objectives and guiding principles in mind:

• Open schema. As noted above, our approach is not to attempt to define a formal and consistent set of schema, taxonomies, or ontologies. Instead we've taken a more organic, community-driven approach where users define and share their own schemas. While there will certainly be overlap and inconsistencies between schemas, the hope is that over time the schemas will evolve and align based on what actually gets used (similar to community-driven "tagging" models).

• Information stored centrally, but accessible from anywhere. N Levels provides a centralized repository for storing information networks, as well as a generic web-based UI for managing them. However, we believe that the real value will come from overlaying and integrating these networks with the current web. Specifically, we enable people to embed object information and object search results within any web page through customizable "widgets" (which do not require any special web server integration). In addition to displaying object properties, these widgets allow visitors to navigate the underlying information network through object relationships, and also to extend those relationships. By separating the underlying "data" from how it is presented and accessed, we hope to empower users to create their own "connected communities" which are distributed across the various web pages, sites, and blogs for those users.

  To give a simple example, below is a N Levels widget which represents information about a fictional softball team. As you can see there are properties which give basic information about the team. In addition, there are relationships which provide further information and which connect the team to other objects, such as the team manager, players, games played for the season, scheduled games, etc.

  Now here is a widget which represents a player on our fictional softball team, which could be embedded in their personal web page. From the widget a visitor to the page could access information about the team, which in turn would lead to discovering more information through the various relationships.

• Provide open but controlled access to information. Currently all of the objects created in N Levels are publicly visible and searchable. (We plan to add more granular access control at some point in the future.) Thus you should only create objects for information that you would be OK authoring on a publicly visible web page. However, we do provide control over who can modify and "connect" objects. Only the owner / creator of the object can modify its properties or delete it. In addition, the object's owner has the ability to control who is able to connect it to other objects through relationships.

  For example, for the softball team object above, the owner could make the "roster member" relationship "closed", so that only they are able to specify who is on the roster. For the "games played" relationship, though, the owner might decide to have it "require approval" - this would allow anyone to add information about games that the team has played, which the owner is required to approve before it becomes visible. Thus if someone tried to add bogus game information, the owner could simply reject it.

We are excited by the potential of information networks, and have created N Levels to provide what will hopefully be a useful service, as well as learn more about what works and what doesn't.

We realize there are some risks inherent in the approach we have taken and figure that the best way to understand them is to build the service and see what happens as it gets used. There are also a large number of feature ideas that we haven't implemented yet but intend to do so in the future. The best way to help us build a useful service is to provide feedback and suggestions on what you'd like to see - you can always send mail to nleveler@nlevels.com (or post comments on this blog).

A big caveat which is also noted on the N Levels site - the service is currently in pre-beta development. This means there will most certainly be some bugs and also that we can't make any guarantees about service availability or data persistence. It's possible that we could lose your data - we don't intend to and will make our best effort to preserve and secure the information you create, but you should not use N Levels to store data that is mission-critical, personal, or sensitive.

Thanks for your interest in N Levels!

First post

Hello - welcome to the N Levels blog! This is a new blog associated with N Levels (www.nlevels.com), a new web service that we are developing. We will use this blog to share information and ideas, and also hope to hear from you through blog comments or email.

Thanks for visiting!