FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:



I've written something really freakin' cool- I'm still working on it, so I don't have time to write more.

But basically, you can build graphs of native data types, and have the graphs span across the world.

Two nifty things:

So, you can-

 person = Ref( "", "PERSON" )
 kitty = { "type": person,
           "name": "Amber Straub" }
 sakura = { "type": person,
            "name": "Sakura Kimbro-Juliao" }
 lion = { "type": Ref( "", "PERSON" ),
          "name": "Lion Kimbro" }
 kitty["kids"] = [sakura]
 lion["kids"] = [sakura]
 sakura["parents"] = [kitty,lion]
 g = Graph( lion )
 print g.serialize()

Then, you give the serialization to someone else.

They do this:

 g = Graph( read_from=big_long_string_description )
 lion = g.start()
 print lion["name"], "has kids:"
 for kid in lion["kids"]:
    print "-->", kid["name"]

Now, it's cool enough that we can communicate these big freaking graphs around.

Now, check this out:

 print lion["type"]

You get back the Ref, right?

But watch this:


Now we type…

 print lion["type"]

…and suddenly, if there is a description of the type on the other end, we get a big fat dictionary, which links to lists and strings and dictionaries and a whole big ball of wax, and there are hoards of Ref's at the ends of those…

…so you have easy access to an enormous data web, spanning the Internet, and entirely in native types!

You could hook up Perl to use this, you could hook up Python to use this, hell, you could even get C code to read these structures and interpret them intelligently..!

Now How Much Would You Pay??!"

But WAIT! There's MORE!

Before, you may have been willing to pay $2,000,000 dollars for this, but wait- hang on- wait till you hear it-

You can even attach Functions and Function-calls to the graph!

 lion["birthyear"] = 1977
 lion["rough-age"] = FuncCall( "calculate-years-since", Ref( g, "START", ["birthyear"] ) )

(Brief explanation in order: "START" is a flag on the graph, automatically assigned when you construct the graph from data to the first reference the constructor was given. ["birthyear"] means "Go out one hop from the START node, by the index "birthyear."")

So, when you serialize out the graph, it has a function call node.

When the graph is read back, it will automatically calculate out the years.

Of course, you have to tell the graph store system "I allow you to bind calculate-years-since to my local function, "calculate_years_since"."

I'm all excited..! :)

Presently, I have the graph serialization and loading working, I have the Ref system almost completely implemented, and I'm about to work on the function capabilities.

You can read more on: OneBigSoup:nLSDgraphs

I'm looking forward to seeing a Perl implementation as well.

It's really actually very simple and basic, when you get down to it. There's no good reason every language can't support something like this.

Here's what something might look like, for immediate use:

 spam_list = { "type": Ref( "", "SPAMLIST" ),
               "author": Ref( "" ),
               "list-type": "perl 5 regex strings",
               "list": [ "", ... ],
               "trusts-lists-from": Ref( "http://" ) }

So, then, I would just tell it to resolve the trusts-lists-from and then the lists in the trusts-lists-from, and bam!

Instant mega list o' lists. {:)}=

You could even have a "combine lists" function in the "trusts-lists-from" definition, and automatically construct the super-list of spammers, all in native code, and with very little manipulation on your part..!

Okay. Back to coding it..!

Lion, what you've developed seems to be very close to two of the Topic Map serialization syntaxes. Topic Maps are basically graph structures, so this might not be too much of a surprise. Topic Maps were designed specifically to allow people to globally share subject-based information (Topics) and mappings between Topics and resources (for more info on Topic Maps, check the easytopicmaps wiki). There's the XML Topic Map (XTM) syntax which is of course XML and verbose, but there's also two simplifications designed for hand-authoring, Linear Topic Map (LTM) and AsTMa=. For example, in LTM the graph you have above would look essentially like this:

   /* topic types */
  [person = "PERSON" @""]
  [parent ; person = "Parent"]
  [child ; person = "Child"]
  [childOf : Hidden = "is child of"]
  /* template provides visualization direction */
  childOf([child] : From, [parent] : To ) / Template
  [sakura : child = "Sakura Kimbro-Juliao" ]
  childOf(sakura : child, [kitty : parent = "Amber Straub" ] : parent )
  childOf(sakura : child, [lion : parent = "Lion Kimbro"] : parent )

This is actually a bit more complicated than is necessary to simply state the expressions you did because I've added in a template to provide Ceryle's visualizer the ability to discern edge direction (i.e., templates are a Ceryle feature, not an LTM feature). But the basics of stating a Topic and then associations between Topics is very similar in your syntax to either LTM or AsTMa?. Here's a visualization of the above LTM file:

But you might take a look at the various syntaxes (particularly LTM and AsTMa=) since they're designed to be human-typeable) for ideas on how the designers have solved some of the problems you're likely to stumble upon eventually. But what you have done so far is very cool! The native datatypes stuff could be quite valuable. You might align it with the XML Schema Datatypes, or at least look at what's there for ideas…


Not to be argumentative- but, I just don't understand how nLSD is more like topic maps than, say, RDF.

I originally thought that what I was writing was a lot like RDF.

But the more I thought about it, I realized, "Wait, this isn't like RDF. You can't take two graphs, and overlay the information in them." (Well, actually, you can, by making use of the "FUNCTION-CALL" nodes- you could make a standard function that took a list for a parameter, and the list describes how to merge the information in the immediate native data with other graphs, and perform all merging specified.)

"OWL" stuff doesn't have much to do with what I just wrote- it's just an Internet-wide native data structure system.

I could see putting RDF on top of nLSD. And from the little I understand of TopicMaps, you could put TopicMaps on top of nLSD as well.

(I mean: Ultimately, eventually, you're dealing with native data structures in your program.)

I was worried that you (MurrayAltheim) were gone, and not reading, because I wanted to tell you something-

I realized that my enthusiasm about the SemanticWeb isn't so much about the way that people decide to do inferencing and correlation and stuff like that- I'm not so concerned about the details.

Mostly what I care about is NetworkedData?. Just the whole idea of making it super-simple to network data at all, across the Internet- that's what really inspired me.

And- I think if you go back, looking at our earlier discussions, you'll see it: CanTheSemanticWebWork : I'm busy talking about networking data, and you're talking about putting intel on top of it. That's why I was attracted to the standards aspect of RDF, whereas you're repulsed by the intel system aspect of it.

I didn't realize it, but I didn't care about the part of the system that you really cared about (and rejected, because they were doing it wrong, by your understanding.)

I really don't know much about DL and stuff like that. I just care (at this point) about hooking data up together with other data, across the Internet, basically seamlessly.

Hey Lion, no, not gone, just at one of those stages where the amount of time I've had to do anything online is at a low ebb. I try to read CW now and then to keep up with the gist of what's going on, but I've been struggling to keep my own stuff up and moving.

Yes, in looking at that conversation I can see what you mean now, and I agree. I have a deep skepticism over the typical claims of the SW, and particularly about the approach being taken to tackle the stated goals. If one connects the dots, they don't lead to the claimed goal at all, and the almost complete absence of computational linguistics (i.e., most everything is based on formal logic) leads me to believe the system will be good for some very specific things, but completely unsuited for others. And those others are the things I believe most people think about when they think "Semantic Web."

The idea of regularized or standardized networked data is obviously so good an idea that the W3C didn't even think about it. RSS took off on its own, and you can tell how popular and important even the heavies think it is by watching their behaviour, e.g., Sun just hired Tim Bray, and Tim's been all about RSS in his talks with the press (see 1, 2). I've certainly found myself disagreeing with Tim on occasion, but the fact that Sun is putting money into RSS, blogs, etc. is a good sign that RSS will get some serious attention.

Now, the way that nLSD is more like Topic Maps is the same way that RSS is different from RDF. RDF is by itself almost semantics-free (almost meaning-free). It's a framework (that's what the "F" is for) upon which you must add some useful semantics in order to build something useful. RSS adds the semantics that make it useful. Topic Maps are a graph-based technology like RDF, but they're like RDF plus a specific set of semantics. Put it this way: if you wanted to create Topic Maps using RDF, you'd create a specific RDF Schema that declared what a specific bunch of URIs meant, then you'd in the schema say how those URIs would be used to augment RDF's syntax in order to build a syntax capable of expressing the semantics of Topic Maps. Topic Maps are a technology that transcend syntax. XML Topic Maps (XTM) is just a specific XML syntax, in a sense implementing a way of serializing a Topic Map in XML syntax so that it can be sent around the web. (I'm not sure if I'm clearing things up here or just muddling it up.)

Now, what you've done has a lot of implied semantics, i.e., there are a lot of assumptions being made about what things mean based on their positions and interrelations. For your purposes this is probably all fine, but you can imagine that it might need to be a hell of a lot more precise in order to work beyond the really simple stuff. For example, at first glance something like a part-whole relationship seems simple. But upon reflection one can see that a person can be a member of a family, a finger can be part of an arm, a hubcap can be part of a car, and a wave can be part of an ocean, but there are dozens of different kinds of part-whole relationship types. A whole field of endeavour called mereology (and a sub-field called mereotopology) studies just this one important relationship type (see 3 and 4).

Anyway, 'nuff said for now. Lion, I don't say any of this to dissuade you from either your enthusiasm or your desire to build crazy-assed new ideas. I'm always inspired by that! The world needs need more Lions!

Thank you. :)


here's a more version:

words → knots

 Lion -> 1
 Kimbro -> 1 7
 lion -> 2
 Amber -> 3
 Straub -> 3
 kitty -> 4
 child -> 6
 Juliao -> 7
 Sakura -> 8
 sakura -> 9
 parents -> 11

knots → knots
connection words: and, does, has, is

 *1 Lion Kimbro -> 2
 *2 lion is *1 -> 5
 *3 Amber Straub -> 4
 *4 kitty is *3 -> 5
 *5 *2 and *4 -> 6 12
 *6 *5 has child -> 10
 *7 Kimbro _ Juliao -> 8
 *8 Sakura *7 -> 9
 *9 sakura is *8 -> 10 11
 *10 *6 is *9 -> 13
 *11 *9 has parents -> 12
 *12 *11 is *5 -> 13
 *13 *10 : *12 
 *14 (left side is folded)


Sigi, I think this is like the first time I've ever understood one of these things that you've written. ;)

I still don't understand the image, though. :(

what do you mean by image? something like intention?

rather the Baum screenshot, I guess. Den Zusammenhang verstehen ist "to get the image"

(Patti Smith: "And this old, rusted polaroid goes crumbling in my hands: I dont get the picture! I don't get the picture!")

Yes, I follow the list, which is a description of the relationships.

I can't make heads or tales of the JPG though.

but thats simple: replace tree by parentheses.
(each bough of the tree corresponds with one (opening or closing) parenthesis.)
the left side (folded version) of the tree means:
((((lion <and> kitty) <has> child) <is> sakura) : ((sakura <has> parents) <is> (lion <and> kitty)))

Oh! I just didn't understand what the "a" and "i" and "h" were all about. :)

I get it now. I just needed your explanation.

Kitty: Why am I always in your examples?

Define external redirect: AsTMa NetworkedData