Comment by: Lion Kimbro · http://lion.taoriver.net/
posted: Jan 12, 2005 2:20:11 PM

I don't understand why you don't like nLSD. Is it the presence of dictionaries, in addition to lists, as a fundamental type, that is the roadblock?

I've already got working code, and you can play with it today. What is wrong with it?

Comment by: Lion Kimbro · http://lion.taoriver.net/
posted: Jan 13, 2005 4:43:05 AM

On the flip side: If you made it so that you can link from to nodes in other graphs, and included dictionaries, and function bindings, and links to function results, I'd be very excited, and would start integrating it into everything I made. {:)}=

Comment by: Jay Fienberg · http://icite.net/blog/
posted: Jan 14, 2005 3:08:29 PM

hi Lion,

Sorry if I suggested that I didn't like nLSD. Actually, I do like it. And, usually, when I use the term "list", I mean it in a more colloquial sense, rather than a purely technical one, e.g., some lists can be used as dictionaries, or a dictionary is something I might describe as a list of terms with definitions.

In the larger picture, I'm just trying to design something a level up, i.e., something that probably could run on top of nLSD. When I get more into the implementation of how the iCite net lists resolve, I'll look a lot more closely at nLSD (and I'd love to not have to duplicate any of your effort if I can build directly on what you've done!!).

Right now, the sub project I'm working on uses lists in a more trivial way, so I'm not quite ready to dive into nLSD and consider how the iCite net might build on top of it, or plug into it (re:, your second comment, which seems possible too!)

Comment by: Lion Kimbro · http://lion.taoriver.net/
posted: Jan 14, 2005 3:43:38 PM

Well, I'm thinking:

You're really intent on working on iCite.

I'd like to work on nLSD right now, but I'm busy with Local Names.

So, I don't know. I'd like to see if I can justify some nLSD ideas for iCite.

The first, most fundamental, idea, I think, is including linking within the format.

Now, if I understand correctly, iCite is a simple way for publishing a list. Not just a simple way of publishing a list, but also: Tools to help you do it. Libraries that you can include in your programs, to read the lists, and process them, and stuff like that.

Now I am saying: "Can we embed the concept of linking to other lists inside iCite?"

That is: Can you make a list of lists?

Now, one thing would to say, "Yes, you can; Include the URLS in the list."

So, before, I might have a list of names: ("Luke", "Lion", "Fen")

To make a list of other lists, we might have: ("http://A", "http://B", "http://C",...)

But, now, I want to suggest taking it a step beyond that.

It would go like this: (http://A, http://B, http://C)

How is that any different?

In the first, we made a list of strings: "http://A", "http://B", "http://C"

When a program reads the list, it will read them off as strings. If you wanted them to be anything other than strings, you'd have to have some special interpreter or something.

ie, if you wanted those to be URLs of lists, you're going to have to write a special layer on top, that interprets them as links to lists; stuff like that.

Okay.

Now, the second, though, is different.

When we say: (http://A, http://B, http://C), we mean that this is a LIST of LISTS, and that to resolve it, you have to go check those other lists.

(Does iCite include lists of lists? I was under the impression that it did.)

So, first, you get: ((...), (...), (...))

Which means: "I've got a list of lists, but I haven't resolved them yet."

Then you use your API, and you say, "Well, let's see that first item. Resolve it for me."

And it pulls up the first item, which was located at http://A. Let's pretend that at http://A, there is a specification for a list: ("foo", "bar", "baz.")

So now our first list, after resolving the first item, reads: (("foo", "bar", "baz"), (...), (...))

Maybe we tell the list, "resolve everything, one level deep."

Then maybe after turning the crank three times, it gives us:

(("foo", "bar", "baz"), ("fee", "fie", "foe", "fum"), ((...), (...), "bang"))

(That is, in the third item, there are two items unresolved.)

(Does this idea make sense?)

The reason you want to do this, is to make it easy for people to make distributed data structures that can span multiple servers.

Think of like FOAF files, how it's neat that they are networked. Or imagine if blogrolls just formed a big data network.

We can make "the Internet" into one gigantic data structure, using these sort of "Networked Data" techniques.

If you played around with it for a while, you would eventually want to link to not just lists, but items within lists, or specific paths within lists. For example, you'd want to say:

(http://A at index 3, http://B at index 6, http://C at index 2)

which might resolve to: ("robot", "alien", "breep")

That is, we're not linking to lists in this case, we're linking to strings at indexes in lists.

This, I believe, is the most important idea in nLSD: "Networked Data."

The rest, I think, is just a natural extension from there.

I'd like to see the idea appear in iCite, and think it would make iCite 100x more useful.

A data structure representing a blog, for instance, would link directly into a neighboring blog's data structure.

It's sort of like pointers in C: It takes you right to the other data structure, there is no need to write special resolver code.

The way the Internet is right now, it's like: For every place that you would follow a pointer in C, you would instead have to call a specific function for accessing the target of the pointer.

Comment awaiting approval
posted: Mar 21, 2006 12:04:55 PM