Sam Sethi is on a roll regarding the semantic web these days.
I see "add semantics" to documents, I hear "add content"...
Actually I have an inkling that some "going down the wrong path" is afoot here.
Absolutely, microformats and RDF can be used for that, but I suspect it's not using the real upside of the semantic web concept.
I've been tinkering, still quite in the theoretical / philosophical sense, with N-triples for thingamy lately, so let me have a go at it. How I skew the situation so to speak. (BTW, here's another triples tutorial)
I see three levels of "information" bearers, or rather three ways to go about supplying information:
1) Documents and forms
This is where we are today, the classic event documentation, ideas summaries or collection of information.
As such they need much on the side to make real use of them. To find them and make use of them they need much knowledge added for which we use tree-structures, tags and links.
If we were to use the semantic web ideas for these invented-for-paper information bearers it would be as advanced tags, added-content-snippets. Neat for sure, but only neat.
Alchemy, no atoms yet.
2) Objects
Atomise a document or form and you can find objects.
This is were we stand with thingamy, cutting up the documents and forms into separate objects each representing a finite real world object. "Address" being a single object representing your house but linked to you and then to your bank account and life insurance.
A few objects can create many, many different documents. Patient object + all the different condition objects and x-ray objects and so forth can create a Patient Journal or some of them can be part of a specific research paper. And so forth.
Having thus one single object per real-world object there is much less need for additional knowledge about the object. Your address is a house. Your broken arm is a condition object.
But still not there, like early nuclear science.
3) (Semantic) Triples
Now, triples consisting of subject + predicate + object can sub-atomise the atomic object.
The beauty of these sub-atoms is that they in themselves are semantic (duh) thus requiring even less knowledge to be added for usefulness. In fact the semantics are much closer to human ways of knowledge transfer than anything else - stories, relationships.
In other words, to use the conceptual ideas stemming from the semantic web to add knowledge, content or semantics to documents or forms would be a waste of something intrinsically more valuable methinks.
Objects can be mashups of N-triples, documents and forms are mashups of objects.
Thus if all is built from bottom up - using say N-triples - then all the objects and documents could be built from fewer particles adding much knowledge enabling simpler finding and better use all in one go.
There is a reason why they invest so much at CERN these days, the days of alchemy should officially be over ;)
Can you give a concrete example of N-triples? How would you use it?
(I'm being lazy and not up to reading the specs ;)
Posted by: Niko Nyman | February 24, 2007 at 22:45
Niko, try the link above "triples tutorial" - it's for AllegroGraph a triplestore (database for triples kind of) by Franz Inc. I think it gives an idea, rather geeky but practical :)
Posted by: sig | February 24, 2007 at 22:55
Could you say that triples do away with encapsulating information about objects inside the objects themselves?
In object-oriented thinking you need to have a Dog object to ask if it is a Mammal. In triples you only need the triplet of "Dog isKindOfA Mammal" to know that. Right...?
Posted by: Niko Nyman | February 25, 2007 at 09:19
Niko, yep - triples could replace the properties of objects, and without properties no need for objects.
A person object could have two properties named "Dog owner?" and "Name of dog".
Here the triples "Fido is a dog" and "Fido has owner Peter" could replace those properties and so forth.
The very, very cool thing is of course how the information ripples through from "mammal" to "Peter's workplace" (not very useful that one, but you get my drift :))
And as said, the information created by triples dishes out real knowledge as it now really tells stories as you follow the relationships. Not like links, tags and content-add-ons, nope a triple _is_ the representative as well as the presenter!
Posted by: sig | February 25, 2007 at 09:35
But is it useful to still talk about objects when using triples? "a Fido" is still different than "the Fido", owned by "the Peter", not just any "Peter". If I understood correctly, the uniqueness of a triples subject is identified by its URI. Or is the URI more like a pointer to a "class"? Or could be both? Eg. an OpenID reference could be an unique identifier when using triples, but an URI reference to "Dog" is more like a class reference. Right.......?
("Learn triples in 5 minutes" continues.. ;)
Posted by: Niko Nyman | February 25, 2007 at 14:23
Niko, you're happily dragging me into deep water here, but I'm not afraid of making a fool of myself so let me... :D
Let me first quote from above "how I skew the situation" - i.e. I would not for a second pretend to be using or even thinking of using triples in the exact way it was meant to be... hehe. It's more of the conceptual - philosophical idea of it that got me interested, the threefold opportunity to 1) sub-atomise the objects, 2) add semantic knowledge directly without "add ons" which would be the natural way of going ahead... I think, and 3) create a completely flexible system to represent an unknown world, no more limits of any kind.
OK, to the details: Absolutely, with triples the need for a data-object to represent something real evaporates.
And yes, we're talking unique triples and not "classes" in those examples.
Looking for something "class"y I would point to the predicate that relates real-world objects; "son of", "owner of", "is of type" etc.
Thus "Fido is a dog" and "Fluffy is a dog" where dog is "described/expanded" through many other triples would describe two unique real world objects.
Cool thing then is the simplicity of adding a new representation of a new real world object.
And if Fluffy has some extra "property" that neither a object class nor a relational table thought of being prepared for you just add that "Fluffy has a big mole". Quite flexible would you not say? :)
Posted by: sig | February 25, 2007 at 16:11
Flexible indeed. I still don't completely get it how you can differentiate between, let's say, Fidos. We've talked about Fido the Dog, owned by Peter, but what if along comes Peter's new girlfriend Carla who by chance also happens to have a Dog, also named Fido. How do we know which Fido is which?
Posted by: Niko Nyman | February 26, 2007 at 06:37
Niko, ouch!
(Wow did you pin-point a sore point here! :D - and now I get your next to last question at last, sorry!)
Ok, *rolling ups sleeves*.
A triples-store is a dumb database but it can handle queries of any combination of s-p-o triples very fast so it all boils down to how you design the triples, and how you design the queries.
Good thing is objects and subjects in the triples can be other triples. That may come in handy.
But as we know real life is not easy - there would be approximately 345,987 Fidos out there, all with different ears and whatnot.
Triples are not restricted to user defined properties (as for objects in OODBs) but can do the job of "unique IDs" too. No end there.
Alas, then some of the fun goes as it gets less semantic in human readable form. Guess that's where the second part of the design comes in - designing the queries so the output gets human readable and story telling like.
There are other paths one can follow here too: Enhance the triples or use as expanded tags for an object oriented approach.
Basically, you have now prompted some serious pressure on my creative vein, hope I find something useful there... but it's fun to tinker with! ;)
More coming... cannot let this hanging around!
Posted by: sig | February 26, 2007 at 11:26
OK Niko, here goes a practical twist:
First think "identity oriented" (typical OODB and thingamy) versus "value oriented" (typical RDBMS) - thus you have a system that "knows" what object you're talking about, i.e. the object and subject part of a triple are in fact real "objects"
Those real data objects would represent a real world object like in thingamy today.
For that one could use a triple, but I would in fact rather keep an atomic object (using an OODB in the back), an object with the bare minimum of properties, the properties that never ever changes (could even be only the ID). Then use that object as the object or subject of unique triples.
The gain would be that object properties would be replaced by semantic triples with full flexibility (no class so to say) and more information given per "property" making tags, links and whatnot redundant. Not to talk about history, there triples could do a nice job!
Yep, think that's my best solution for now ;)
Posted by: sig | February 26, 2007 at 12:25
But is it useful to still talk about objects when using triples? "a Fido" is still different than "the Fido", owned by "the Peter", not just any "Peter".http://www.spotesya.com/
Posted by: Martin | July 11, 2007 at 17:46
Martin, risking more deep water wading here: The triples have three levels of "objects" the subject-predicate-object, three of the only four properties, last being ID for the triples-object. Then it is what object does a triples object represent... and then the water gets murky...
The power of the triples are the relationships between objects described by the properties thus creating knowledge directly.
Me thinks much fun will be had when we start tinkering with it for purposes beyond it's original purpose and that will probably raise more questions than answers for awhile!
Posted by: sig | July 11, 2007 at 22:12
And a bit more, found a real good one here: http://www.robertprice.co.uk/robblog/archive/2004/10/What_Is_An_RDF_Triple_.shtml
Comparing objects as we know them - in triples the "subject" is a unique.. eh subject like "the Fido" above while the "predicate" points to the usual object's properties like "has owner" or "has name" while the triples "object" then becomes the value of that usual object's property - "Peter" or "Fido". "Peter" there would be a "pointer" to a "subject" describing "the Peter".
Confusing? Sure, but the neat thing about triples is that each is true and independent of others. That's why I see "Documents" as mashups (molecules) of objects (atoms) that again can be mashups of triples! And the smaller and truer and more unique a part is the simpler the system becomes at the end - very complicated stuff (say documents with all kind of meta knowledge like links) can be built.
Posted by: sig | July 12, 2007 at 10:05
ut is it useful to still talk about objects when using triples? "a Fido" is still different than "the Fido", owned by "the Peter", not just any
Posted by: ikinci el eşya ankara ve ikinci el eşya alanlar ankara | September 19, 2011 at 11:43
Good point of course - I'd say it's no more "necessary" but might still be "useful".
We've chosen a hybrid in fact for different reasons, but could in fact move over to pure semantic web if we find that useful.
Posted by: sig | September 19, 2011 at 11:55