<$BlogRSDUrl$>

Thursday, July 10, 2003

The real work of metadata driven architecture 

To jump straight to the punch line, 1. In order for a user to enter information, you need a GUI, although a small pidgin may sometimes be enough. 2. In order to merge information syntactically, you need XML, although a small subset of XML is often enough. 3. In order to merge information semantically, you need a Topic Map, although RDF is often enough. The real work is in building the GUI, and the transform that converts it to a topic map. Not to mention, performing the work for which all this machinery was originally intended.

(0) comments

Wednesday, July 09, 2003

Typed Links and Knowledge Representation 

This idea of a "typed link" immediately leads to the question of what language to cast these representations. Bryan Thompson has been discussing with Me the possibility of using RDF or topic maps as a representational approach and how that might contrasts with using a small domain specific language built on XML or a pidgin syntax. One of the traps with this kind of discussion, is to mix similar sounding representations operating at different levels. Are we trying to decribe the metadata needed to declaratively defines a report, or are we talking about how a report relates to other documents to provide positions and evidence relating to an issue or argument? We might also be talking about how information in reports can be aggregated or how the aggregation of different report evaluations might be used to support different argument positions. We might be using the report in a reasoning system in order to support some kind of inference. Each one of these positions has representational implications. While there is a tendency to try and be as general an unconstrained as possible, this can often lead to increased complexity and unecessary redundency. If you do something very simple and domain specific, you might make the integration with other systems more difficult. What is a user willing to input? #xml <report report-id = "1"> <institution-list> <institution inst-id="1" /> <institution inst-id="2" /> </institution-list> <market> <location state="CA" county="123" /> <location state="VA" county="234" /> </market> </report> #pidgin 1 report{report-id="1" institution-list{inst-id="1" inst-id="2"} market{ location{state="CA" county="123"} location{ state="VA" county="234" }}} #pidgin 2 [report: 1 [institutions: 1 2] [market: [location:CA 123] [location:VA 234]]] #pidgin 3 [report: 1 [1 2][[CA 123][VA 234]]] #rdf <report id="r1"><includes><institution id="i1"> <report id="r1"><includes><institutionlist id="il1"> <report id="r1"><includes><market id="m1"> <institutionlist id="il1"><includes><institution id="i1"> <institutionlist id="il1"><includes><institution id="i2"> <market id="m1"><includes><location id="l1"> <market id="m1"><includes><location id="l2"> <location id="l1"><includes><state id="s1"> <location id="l1"><includes><county id="c1"> <location id="l2"><includes><state id="s2"> <location id="l2"><includes><county id="c2"> #topicmap <topic id=report > <basename>report</basename> <occurrence id=r1 /> </topic> <topic id=institution > <basename>institution</basename> </topic> <topic id=i1 > <basename>institution 1</basename> </topic> <topic id=i2 > <basename>institution 2</basename> </topic> <topic id=market > <basename>market</basename> </topic> <topic id=m1 > <basename>market 1</basename> </topic> <topic id=location > <basename>location</basename> </topic> <topic id=l1 > <basename>location 1</basename> </topic> <topic id=l2 > <basename>location 2</basename> </topic> <topic id=state > <basename>state</basename> </topic> <topic id=s1 > <basename>state 1</basename> </topic> <topic id=s2 > <basename>state 2</basename> </topic> <topic id=county > <basename>county</basename> </topic> <topic id=c1 > <basename>county 1</basename> </topic> <topic id=c2 > <basename>county 2</basename> </topic> <association id=r1> <instanceOf> <topicRef xlink:href="#report"/> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#institution-list"/> </roleSpec> <topicRef xlink:href="#il1"/> </member> <member> <roleSpec> <topicRef xlink:href="#market"/> </roleSpec> <topicRef xlink:href="#m1"/> </member> </association> <association> <instanceOf> <topicRef xlink:href="#il1"/> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#institution"/> </roleSpec> <topicRef xlink:href="#i1"/> </member> <member> <roleSpec> <topicRef xlink:href="#institution"/> </roleSpec> <topicRef xlink:href="#i2"/> </member> </association> <association> <instanceOf> <topicRef xlink:href="#m1"/> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#location"/> </roleSpec> <topicRef xlink:href="#l1"/> </member> <member> <roleSpec> <topicRef xlink:href="#location"/> </roleSpec> <topicRef xlink:href="#l2"/> </member> </association> <association> <instanceOf> <topicRef xlink:href="#l1"/> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#state"/> </roleSpec> <topicRef xlink:href="#s1"/> </member> <member> <roleSpec> <topicRef xlink:href="#county"/> </roleSpec> <topicRef xlink:href="#c1"/> </member> </association> <association> <instanceOf> <topicRef xlink:href="#l2"/> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#state"/> </roleSpec> <topicRef xlink:href="#s2"/> </member> <member> <roleSpec> <topicRef xlink:href="#county"/> </roleSpec> <topicRef xlink:href="#c2"/> </member> </association> </topicMap>

(0) comments

Using Wiki Pidgin Languages to Dynamically Create Links for a Read/Write Web 

A Wiki should be able to use a pidgin to create a lazily defined link. For example, a reporting application should be able to convert a user entry of [report: 234] into a link to a report with id 234 or [report-table: 234 T1] to a link to a report table. To do this the Wiki-ish client must parse the delimited text, input by the user, and do a GET on a generated URL. This implies that the Wiki-ish client understands the "report" and "report-table" types. Understanding -- means that it can parse the user input to generated a URL and interpret the HTTP response. It would be nice if there was some way to automatically plug-in a standard way of "understanding a service", however, it will more likely require design time coding in the Wiki-ish client. If the HTTP response indicates that a resource does exist, for the user's input, then the client must know how to create a link or embedding of that resource into the representation of the client page. If the HTTP response indicates that no resource exists, the client needs to be able to generate an appropriate behavior. This could be an error message, or a GET to a service that can return a resource creation representation (i.e. an HTML Form that can be filled out and posted to create a resource). It might also create a link to the resource creation page, where the resource can be created at a later date (Wiki style lazy creation of references). If the user hasn't completely specified what the resource is or there is some ambiguity in the user input, then the client may immediately forward the user to a partially filled out input form, or some other input mechanism for completing and creating a representation. The client, however, may also encode it's best interpretation of the user's input into a lazy link to the resource creation page. This inline representation could then be edited by the user, or clicked through to edit the client supplied information and create the resource.

(0) comments

Monday, July 07, 2003

The Philosophical Basis of Knowledge Representation and the Web 

I have come to the conclusion that it is really Peirce's distinctions of Qualisign, SinSign and Legisign (tone, token, type) that is more relevant to my understanding of how the web in general and weblogs and wikis in particular, may evolve. I see a raw blog as representative of a tone. It is an expression of natural language that has no definite interpretation or bounded meaning. I see the URI or URL as a manifestation of a token. It is a pointer of arbitrary form to a specific thing. One of the main functions of pidgins (a term used that I have borrowed from Bryan Thompson to describe a simple easy to use set of language gestures) is to provide a convenient way of generating links to lazily created content on a Wiki. What I think is missing is the ability to identify type information. Stating the obvious -- only when formal distinctions between issue, position and support etc. are made can something like an IBIS system (Issues based information system -- also from Bryan) a reality. It is type information that allows meaningful abstraction and aggregation, combining apples with apples and oranges with oranges, as well as the proper proportions in a fruit salad. While pidgin can be used for formatting and other things, we are primarily talking about the creation of a link, or a token that sits in a sea of tones and points to another sea of tones. In order to move beyond just pouring more water into the ocean, we need a system of types out of which a structure of knowledge can grow and evolve. Originally, I tried to add all kinds of representational distinctions to an increasingly complex local language. However, now I am seeing a more limited role for a pidgin, as a way of designating typed links. Most current Wiki pidgins are just creating links to tones, so there is no need for type information. In an IBIS system, instead of [tone1] and [tone2], which is turned into <a href="token1">tone1</a>, <a href="token2">tone2</a>; we will need to represent [type1: tone1] which is turned into <type1><a href="token1">tone1</a></type1>. The representational complexity is not within the tone of the page with the pidgin, but what is pointed to, external to the page. It is only important that the pidgin be able to create a typed link. It is up to the external system to provide a context for the creation, editing, and representation of a resource. This may be through a GUI, XML or some or other kind of representational system, which is as simple or as complex as it needs to be. However, I may now have constrained what I mean by pidgin to be something so small, that it may no longer be valid to refer to it as a pidgin. Interestingly, this also seems to align with Peirce's other triple: Icon, Index, Symbol <Symbol:Type1><a href='IndexToken1'>IconTone1</a></SymbolType>. Here there seems to be a relationship between symbol and namespace, the indexical function of a URL and the iconic text or picture that is associated with the link.

(0) comments

This page is powered by Blogger. Isn't yours?