http://www.w3.org/RDF/ - The Resource Description Framework (RDF) integrates a variety of applications from library catalogs and world-wide directories to syndication and aggregation of news, software, and content to personal collections of music, photos, and events using XML as an interchange syntax. The RDF specifications provide a lightweight ontology system to support the exchange of knowledge on the Web.
Very roughly, RDF tries to boil down the entire universe of semantic relationships among Internet resources into a series of three-part statements. For example, you might have:
Only instead of Wiki pages, RDF says that each member of the triple is a web resource identified by a full URI.
Most importanty, the properties themselves can also become resources, and then you can define semantic properties of the properties themselves.
The "triples" concept is compelling. If you add more content to the atomic statements of the semantic web, you add a lot of complexity. On the other hand, if you went to "doubles" instead of "triples," you can only express the trivial relationship of linking.
Wikis now only define "double" relationships between Wiki pages. This still leads to pretty rich semantic inferences, such as backlink searches, inferred LocalSiteMaps, etc., but it gets to be limiting after a while.
I propose that Wiki extensions support searches on Wiki triples. If you want to define a triple on a Wiki, you would use the following syntax:
This implicitly defines the triple:
There is no constraint on properties for any given wiki. If you want something to be a property, just make a Wiki page for it. And, of course, on the Wiki page, you can describe the semantics more richly. SeeAlso could be one property, for example.
The "triple search" feature would consist of three edit boxes, one for each slot of the triple. You would match on as many fields as you want.
See also: MetadataSyntax
At first a Wiki might implement just a basic search on triples, but eventually Wikis could implement semantics for certain properties. For example, a Wiki might implement the semantics for Subclasses in its search. (Subclasses would actually be a Wiki word.)
If you have the triples (IsAnApplicationOf, Subclasses, SeeAlso) and (RdfForWikis, IsAnApplicationOf, ResourceDescriptionFramework), then a search on (RdfForWikis, SeeAlso, *) would turn up (RdfForWikis, IsAnApplicationOf, ResourceDescriptionFramework). The Subclasses properties would have these semantics:
(A, Subclasses, B) and (X, A, Y) -> (X, B, Y)
I've been using the Category notion at allmyfaqs.com. For instance http://allmyfaqs.com/faq.pl?search=Category+HTML+Tables gives a quite useful listing. You get the same layout with http://allmyfaqs.com/faq.pl?search=category+html+tables -- the lowercase entry in the Search box as opposed to the click-link-then-click-title that gives you the first version. I could go one step further, and and make the Category link at the top of each page a direct search link (intermap macro) to give the effect the links here http://allmyfaqs.com/faq.pl?How_do_I_center_a_table has. Then I can do away with menu-level pages like http://allmyfaqs.com/faq.pl?HTML_Tables ... maybe.
Jumping through the extra hoops is a requirement for pages accessed by nonwikigeeks. For a geek environment, I would try a keyword top line for each page, and use regexp searches to show relationships --
A search for ,patient.*,screen is one slice giving definitions plus examples plus procedures (etc.) pertaining to patient screen, whereas ,defines,.*field is a different slice through the knowledge base, giving a list of definitions for all fields for all screens in the system.
I'd like to get the utility of [mapping] without the notational overhead.
The approach (RDF or categories or comma-keys) is certainly valuable to explore and refine, with huge benefits in applications producing structured documentation fron single-source authoring systems. -- JerryMuelver
I was working on something like this for CrystalPalace. The problem of turning arbitrary relationships between entities into first class objects seemed very difficult without limiting the set, but these triplet semantics seem very workable. As they say, just add another layer of indirection. -- SunirShah
I've started spiking this on PeriPeri. However, I didn't think it was useful to have page names as properties. To start, I've allowed any page to have DublinCore attributes added, and the obvious implications inferred. See PeriPeri:PeriPeri+FacetWiki:RdfForWikis. -- ChrisPurcell
Exactly my point! The page [NeuroWiki:HippocampalBasketCell] says "Also known as perisomatic inhibitory cells" and also "These interneurons are necessary for the HippocampalThetaRhythm", and the hippocampalThetaRhythm is a type of oscillation (in fact, the page is even in NeuroWiki's categoryOscillation). A human who read both pages would know that, but the computer doesn't. With RDF we can give the computer this sort of reasoning. -- BayleShanks
How does that googled reference relate in any way to the question? It describes a neuron modelling system, and cites a paper mentioning oscillation. That either highlights the existing problem, which Bayle asserts could be fixed by RDF, or demonstrates that I misunderstood the referenced page. -- ChrisPurcell
Shrug, I don't know that much about neurology. I also found http://citeseer.nj.nec.com/wang96gamma.html. Google was closer though. Neither system is perfect. Even Google is expensive, as it requires a large page database to be effective. Did you ever use http://google.stanford.edu? Not that good at even data central to its database.
Another solution would have two text queries. One "inhibit* neuron*" and another with "oscillat*" and then find the intersection 0, 1, 2 links away. RDF could help identify the links, but I wonder if it would really be all that necessary. Speaking of which, that would be a fun module to code up for a wiki. The visualization would be easy enough, where P represents a WikiName of somesort
P P 0 links away (same page) P P P --> P P --> P 1 link away. forward link from 1->2. P --> P P <-- P P <-- P 1 link away. forward link from 2->1. P <-- P P --> P --> P 2 links away, all permutations. P <-- P <-- P P(italics) represents the inbetween page. P <-- P --> P P --> P <-- P
Incidentally, I did an AI project attempting to use this technique ("which node is closer" or you might call it "spreading activation similarity metric") to match pronouns with antecedents in natural language processing. For example, in the sentence "Roger bought a candle using his credit card, and then put it back into his wallet"; does "it" refer to "candle", or to "card" ("it" refers to "card", actually, but we want the computer to figure that out). I forgot exactly what I did, but it was something like comparing d("candle","wallet") to d("card","wallet") in the AIWiki:WordNet? database and taking the closer node. It didn't work. But then, maybe I didn't do it right; it was only a week-long project. -- BayleShanks
I do not quite understand all the ideas and implications here, but I think that there are a lot of connections to the ideas of WikiVirtualData. This is as partially implemented in FractalWiki and in another modelling project. -- HelmutLeitner
Have you read much about ResourceDescriptionFramework? -- ChrisPurcell No, only what's on this page. Of course I do not think that virtual data does RDF. But the ideas of WikiVirtualData provide an abstract technical framework to do and talk about and implement such things, because syntax and searching and the database aspects can already be relied upon. -- HelmutLeitner
Not long time ago there started the development of an uniqueID and relationship manager to make content "placeless" meaning independent from any ie. hierarchical order, so all pieces of content can be put together in various collections withour caring for the location it's stored - to come to the point, this concept is also suitable to implement RDF and also TopicMaps? (which is my favourite - both can also work together in a certain degree, TMs are just much more sophisticated, so I try to build TM support for ZWiki currently) - see http://plone.org/development/current/projects/Ticle/view FlorianKonnertz, 03-10-25