[
Lists Home |
Date Index |
Thread Index
]
Hi Joe,
On 7/5/05, Joe Schaffner <schaffner.joe@gmail.com> wrote:
> Can you recommend an XSD validator?
Not sure why you would want to do this in XSD, and I personally would
use RELAX-NG, but even DTD is good enough for your simple stuff here?
> I want a simple one, a command line filter, one which works on stdio, the
> schema as the only argument. I hate rpms, so a small collection of
> statically-linked, command-line filters is what I want. No Java RTE, s'il
> vous plait. I'm using SuSE 9.2. Linux. Also, an XSL processor?
Look up libxml and libxslt, which is what I would recomend, unless you
want to do the whole Java thing, in which probably Saxon would suit
your needs more than well enough.
...
> Today I was linking all the verbs which express "luck" - &tgr;&uacgr;&khgr;&eegr; - like: {&agr;&tgr;&ugr;&khgr;&ohacgr;
> (I have no luck), &egr;&ugr;&tgr;&ugr;&khgr;&ohacgr; (I have good luck), &dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr; (I have bad luck),
> &pgr;&egr;&tgr;&ugr;&khgr;&agr;&iacgr;&ngr;&ohgr; (I succeed)}.
>
> Over time, the conjugations have changed, so the verbs belong to different
> morpological models. Now they're all on the same list, linked on the
> (English) meaning!
Here's a part of your ontology ;
<item id="luck">
<name>&tgr;&uacgr;&khgr;&eegr;</name>
<name lang="en">luck</name>
<type>expression</type>
</item>
And here are verbs using that ontology (see '<type>luck</type>' ) ;
<item id="&agr;&tgr;&ugr;&khgr;&ohacgr;">
<type>luck</type>
<name>&agr;&tgr;&ugr;&khgr;&ohacgr;</name>
<name lang="en">I have no luck</name>
</item>
<item id="&egr;&ugr;&tgr;&ugr;&khgr;&ohacgr;">
<type>luck</type>
<name>&egr;&ugr;&tgr;&ugr;&khgr;&ohacgr;</name>
<name lang="en">I have good luck</name>
</item>
The advantage is that you could use multiple types to declare other
properties easily ;
<item id="&dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr;">
<type>luck</type>
<type>bad</type> <!-- also of a bad type -->
<name>&dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr;</name>
<name lang="en">I have bad luck</name>
</item>
Now you can map your semantics between typed items to get that model
you were talking about earlier. But you can also take a different (or
additional) approach with this (very bogus) example to describe
multi-relationships ;
<relationship id="3945">
<type refid="morphology" />
<item refid="&dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr;" role="medio-passive" />
<item refid="syntax" role="schema-old-greek" />
<item refid="reflexive" role="verb-type" />
</relationship>
Now you can type your relationships, and chucking id's on the
<relationship /> you can talk about this relationships in other
relationships, which would be *exactly* what you want if you wanted to
give examples.
> I want the metadata to remain in the application domain where I see it.
Umm, isn't this just about where you store your definitions? Are you
saying that you want to store your stuff in a C++ source file because
that's where you want to maintain it? The what do you need XML /
schema for? Just the presentation?
> Yes, you're right, it's just relating(=linking) objects by property. The
> semantics are defined in the application domain by the members of the list,
> not in a data dictionary maintained by the compiler.
I'm sorry, I don't understand; what is maintained by the compiler, and
what is meant by 'application domain' here?
> Coming up with names for the lists can be hard. In fact, the name of the
> list is really the string of entries in list itself. Kind of reminds me of
> the name of God himself, which was the string of all the letters and words
> in the books of the Bible...
this is what's known as ontology work, really; you've got some items
and you try to pin a label on the group, defining what they're all
about. After you've defined and defined some more, you got some kind
of model to show for it. It sometimes work, and often it doesn't work
at all. It depends on how good you are at flexibility.
> (God as the primary abstraction? Sometimes He is defined as "top" in the
> books, "top cat", "top sergeant"... the primary abstraction from which all
> others flow, a pure, virtual class.)
Nothing -> something -> Everything :)
> All the verbs having similar, oposite, or otherwise related meaning will be
> placed on the same list. A curious student is encouraged to push on the link
> to see what follows.
Why not create an interface that enables such behaviour by default?
> (It's sort of like an IQ test question, you know, which word does not belong
> to the list of choices?)
Again, if you can define a context, all relationships within it can be
described, but as long as you keep something in the compiler / C++
source files and something in XML, this can be very hard to sort out
and make useful.
> I want to keep the lists short, maybe 3, 4 or 5 entries each, otherwise the
> meanings start to diverge and you are left wondering what the idea was in
> the first place.
Again, I think the idea of lists are going to fail you in the long
run; there will be so many little lists with similar or opposite or
near or totally wrong meanings. Why not define each verb with its
relationships and let the application work out automagically what the
model might look like? This way you've got a stronger foundation, and
you don't have to worry about it at all.
> Opposites, like {love, hate}, {come, go}, {eat, drink}, {walk, run} are the
> most interesting categories and have separate lists.
> The case of "being" {is, becomes, exists, appears, remains} is pretty tight.
>
> &ggr;&egr;&ngr;&ngr;&eeacgr;&thgr;&eegr;&kgr;&agr; - I was born.
> &mgr;&egr;&ggr;&aacgr;&lgr;&ohgr;&sgr;&agr; - I was raised
> &pgr;&eacgr;&thgr;&agr;&ngr;&agr; - I died
>
> All three belong to different models, but are related by meaning. What is
> that meaning? Who knows, they just go together.
This is an untyped relationship where roles are undefined;
<relationship id="2356">
<name>Somewhat related</name>
<item refid="&ggr;&egr;&ngr;&ngr;&eeacgr;&thgr;&eegr;&kgr;&agr;" />
<item refid="&mgr;&egr;&ggr;&aacgr;&lgr;&ohgr;&sgr;&agr;" />
<item refid="&pgr;&eacgr;&thgr;&agr;&ngr;&agr;" />
</relationship>
If you are on the page talking about '&ggr;&egr;&ngr;&ngr;&eeacgr;&thgr;&eegr;&kgr;&agr;', it will also list
this relationship with it. If you now want to *talk* about this
relationship ;
<item id="reified-2356">
<name lang="en">The 'somewhat related' relationship</name>
...
</item>
Simple.
> The curious thing about the morphology is that the first is medio-passive,
> because it refers to "self", like a reflexive verb, but the other two are
> active intransitives. (You'd expect them all to be medio-passive, but
> they're not.)
Define your ontology as such ;
<item id="self">
<type>role</role>
<name>reflexive</name>
</item>
<item id="active-intransitive">
<type>role</role>
<name>active intransitive</name>
</item>
Now you can talk about these things in your relationships if you want to ;
<item refid="&mgr;&egr;&ggr;&aacgr;&lgr;&ohgr;&sgr;&agr;" role="active-intransitive" />
Migth make a nifty user-interface to your dataset.
> I'm definining them as I go. It's a blast.
That's the key, isn't it; have fun! :)
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________
|
