RE: HM.applications-Translations

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Or you use SELECT statements and filters.  It is just 
a pipeline of views.  The important thing is to have 
the classes and properties well-defined in an exchangeable 
representation.  Before you get there, you need an 
authoritative reliable source.  That is the "opinion" 
issue the topic map people discuss and a part of the 
namespace identity and location conflation snafu.  
PUBLIC names exist to associate organizations (authorities) 
to names such that it is a clear legal assertion.  
It seems tendentious but it is important because 
authoritative information should be independent of 
the transport medium.

DLGs?  (Graphs I assume?)

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Sean B. Palmer [mailto:sean@mysterylights.com]
Sent: Wednesday, September 05, 2001 6:23 PM
To: Mark Brownell; Bullard, Claude L (Len);
humanmarkup-comment@lists.oasis-open.org
Subject: Re: HM.applications-Translations


> [...] I mean an equivalent consideration for the Sierra
> Madre in Mexico could also be a cultural fit for this
> element value. So how do you get machines to draw
> the connection?

You could have a profile for the document that explains the cultural
connections of the author, and then augment the data within the instance
according to that profile upon delivery to the user.

The way you'd do it using RDF annotations is probably to assign a context
to the document, and then have an anonymous node with a lexical value
representing the "Sierras".

   [ :lexVal "Sierra" ] .

Then, when you take into account something like:-

   [ :authorOf this; :nationality :Mexican ] .

You can conclude that:-

   [ :lexVal "Sierra" ] :probablyMeansInThisContext
     [ :lexVal "Sierra Madre" ] .

Or whatever. You'd need a rulebase containing FOPL statements for it to
work, but that's coming along.

Tip: think in terms of DLGs laid on top of structural XML.