Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Data vs. Process was Re: Vocabulary Combination
 jonathan@o... (Jonathan Borden) writes: >> jonathan@o... (Jonathan Borden) writes: >> >When I think about ontologies I hardly think about processing at >> >all. How exactly do ontologies intrude into your choices about >> >processing? >> >> I see the meaning of markup as coming from the reader, whether that >> reader is a human or a computer process. Ontologies strike me as a >> deliberate effort to enforce a particular set of meanings across >> processing contexts, so in that sense they affect the possibilities >> I had open in my processing. >> > >Fair enough. For certain, some types of writing are meant to be >interpreted primarily if not completely by the reader, for example >poetry. There are, of course, poets (and definitely novelists) who have little patience for the notion that meaning derives from the consumer rather than the creator. >Other types of writing are meant to be interpreted exactly by >the reader as written by the author, for example: a medical >prescription. Prescriptions have a long and complex history. Pharmacists used to have a good deal of discretion in how they filled out prescriptions, and they certainly still have a role in cases where the pharmacist sees a drug interaction that the doctor does not. "Dispense As Written" is a current battlefield between doctors and insurers. There are a lot of often conflicting perspectives here. >Other documents are intended to fall somewhere in between. I'd suggest that all documents fall in between, regardless of intention. >Ontologies _are_ an effort to proscribe a deliberate _set of meanings_ >(as you write, this is spot on) between the reader and writer (i.e. >across processing contexts if you wish to use this language). I hope >you will allow that there are certain tasks for which it is essential >that the reader and writer share a common understanding of the >document (e.g. medical documentation). Such efforts, insofar as they acknowledge that they are contingent results, subject to further development and interpretation, may be useful for categorizing and describing information. Unfortunately that kind of acknowledgment of uncertainty seems frequently to fall to grander visions of a unifiable representation of 'knowledge'. Common understandings are useful, but I regard most ontology work as an effort to create global understandings where local understandings are both more flexible and workable without being globalized. >> Beyond that, expectations that processing will be flexible enough to >> handle changes in ontologies requires writing the processing in a >> very different style, requiring my code to understand the ontologies >> rather than just the markup. >> >> It may be declarative, but its impact reaches to the core of the >> code. > >Ah, you expect your code to handle potential changes in the way the >"world" is constructed! An admirable goal, but one not obtained by any >software I know of. I certainly know little "code" that actually >understands any extensive ontology I've seen -- perhaps we can start >enrolling PCs in medical school in the next few years :-))) >.... No, I don't expect my code to handle such changes. I do, however, hear regular suggestions that ontologies provide a useful mechanism for communicating such changes (and certainly alternate representations) to programs - and that ontologies and code written around ontologies are therefore more adaptive. >> Thanks, but I don't need or want those burdens. It's not black >> magic - it's merely naive faith in the coherence of logical >> constructions built in a certain way of supposedly atomic facts. I >> don't trust the premise, and I don't want the tools. >> >> Markup's premises are a lot smaller, far easier to comprehend, and >> involve a lot less sleight of hand. > >Of course that is entirely true. > >It comes down to what you are trying to do. For certain tasks, such as >those I frequently give examples of, dealing with markup _alone_ >doesn't solve the entire problem. Markup alone solves no problems. Markup in particular contexts can be very useful. You seem to find the creation of global contexts useful, while I find them constraining and overwhelmingly tied to information politics rather than technical need. Markup feels to me like an opportunity to avoid such over-ambitious projects by letting people label information using terms that are meaningful to them - and subject to later interpretation. >It's not helpful to me if you >criticize a solution to a problem, without explaining an alternate >solution. It's sort of like complaining that modern CPUs have too many >transistors ... it may indeed be true, and it may be a noble goal of >the computer industry to reduce the complexity of the next generation >of CPUs, but for a guy that wants to transfer copies of DVs of his >kids to a DVD, I really don't friggin' care about much except how much >time I am sitting in front of the screen waiting for this task to get >completed. I think you've wandered off into irrelevant comparisons here. >So please, if you are going to off hand dismiss my solutions, the >least you can do is to try to understand the problems I am trying to >solve. "Don't do that" doesn't quite cut it. "Don't encourage that as a general solution" seems quite completely appropriate to me. I lack sympathy for the problem-solving approach you've chosen. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com -- http://monasticxml.org 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
