[
Lists Home |
Date Index |
Thread Index
]
"Not sure what an XML object might be, but xPath is simply a query
language for traversing node-trees, and a very good one as such."
1) I was thinking "an instance of anything defined by a schema --maybe a top-level schema, a public object".
2) Something that can be tagged.
3) Something, like a verb, that could exist at the top level of a document and could be pointed to by some kind of link. For example, verbs related semantically, like verbs of being, could be linked. Check out:
Είμαι is on a list of verbs of being... For the moment, I'm using a hyperlink on the English translation to get to the verbs which have similar meaning.
"Navigation should not be part of your datamodel nor dataset, but be a
separate implementation detail. Here's how I'd do your XML stuff;
<term id="some.id.x">
<label lang="en">Fiddle</label>
<label lang="no">Fele</label>
</term>
<term id="some.id.y">
<label lang="en">Chin</label>
<label lang="no">Hake</label>
</term>
And when you need a relationship between the two;
<relationship of.type="played.on">
<member refid="some.id.x" role="instrument" />
<member refid="
some.id.y" role="method" />
</relationship>
Then it makes sense to just create a set of words that describe your
relationships (of.type and role attributes) (also known as an
ontology). This can now all come together in a user interface without
any hardwireing."
I like your language, but I don't like making up names when they already exist. Each verb names its meaning already.
To me, "navigation" does not necessarily mean visual transversal. My program might like to iterate on the list, so the list would have to be named, formally, as in an XLink, whatever that might look like.
(Internal objects would normally be hidden and not referenced from the outside, but could, from the inside. That's not an issue now.)
You can see, I'm working with a familiar model, taken from C++.
Pointers are indeed "hardwired" but they are intuitive, at least to me.
(Maybe you'd prefer the modern term, a "reference.")
I'm working with a single data type which applies to all the verbs. I don't really want to define subtypes which merely model the structure of the verbs. The structure is basically the same for all verbs. Intransitives have no passive, Transitives should... some verbs are defective -- missing principal parts, but the missing parts can be null.
In my sleep, I see a web of verbs, a semantic web, linked with references, not definitionally.
The navigation occurs on two levels, the visual level, the one we're already familiar with using HTML, and another, in fact, any number of logical levels. A verb could belong to many semantic categories, like transitives, intransitives, emotion, motion, being, mood, love, hate etc.
"Hardwiring" using links between (XML) objects (or data structures, if you prefer) seems more flexible to me. It's also intuitive in the sense that I can create the categories as I go, without having to rely on another dictionary (the schema) of concepts and the relationships between them.
In other words, I'd like to keep the formal model as simple as possible: I want as few "types" as possible, maybe only one. Then I merely create named, linked lists which tie all the instances together. A processing program would follow the links on a named list. Any verb belonging to the (semantic) category would be a node in the list. Any node can belong to as many lists as I want. The name of the list would be the name of the category.
I'm still thinking... For the moment I'm going to expand the dictionary to about 500 pages, one verb (object) per page, and link them informally using html hyperlinks. Then I'll get to know how the verbs behave structurally. Of course, the hyperlinks are not named, so they'll be useless to anyone but a human :)
The reason I want to move to XML is because the physical appearance of the page as it currently exists might not be appropriate to all uses. Some people may even want a query language which only returns certain voices, moods, or tenses...
The structure of each page already resembles the most logical configuration I could think of, and could be translated to XML by replacing the <table> and <td> tags with the "titles" of the columns and rows.
You may be wondering why I didn't do to XML first.
1) I needed immediate gratification.
2) I haven't fully absorbed all the implications of the related technologies, like XLink and XPath.
3) The tools... I don't like surprises.
Thanks for your help. If you understand the world as I've just described it you could help me by defining the XML jargon in these terms.
Thanks again,
Joe
On 6/29/05, Alexander Johannesen <alexander.johannesen@gmail.com> wrote:
Hi Joe,
On 6/29/05, Joe Schaffner <schaffner.joe@gmail.com
> wrote:
> XPath looks like some kind of expression language for naming objects, as in
> "pathname", not a "link". (I'm guessing that XML objects, being
> hierarchical, need some kind of name syntax, like a "pathname".)
Not sure what an XML object might be, but xPath is simply a query
language for traversing node-trees, and a very good one as such.
> The 'link' abstraction in XML is a bit more complicated than I expected, so
> I'll need more time to read the documentation.
Of course, that depends on just how you model and want to implement your data.
> My names <prev> and <next> come from linked list programming in C. They are
> unidirectional, so you need one for both directions. They serve as
> navigation.
Navigation should not be part of your datamodel nor dataset, but be a
separate implementation detail. Here's how I'd do your XML stuff;
<term id="some.id.x">
<label lang="en">Fiddle</label>
<label lang="no">Fele</label>
</term>
<term id="some.id.y">
<label lang="en">Chin</label>
<label lang="no">Hake</label>
</term>
And when you need a relationship between the two;
<relationship of.type=
"played.on">
<member refid="some.id.x" role="instrument" />
<member refid="some.id.y" role="method" />
</relationship>
Then it makes sense to just create a set of words that describe your
relationships (of.type and role attributes) (also known as an
ontology). This can now all come together in a user interface without
any hardwireing.
You may want to look at canonical XML for a better understanding of id
and refid attributes and somesuch. xLink is when you need (well,
mostly) cross-document linking, and *especially* cross-domain
cross-linking. Basically my advice would be to keep it simple unless
you really have to.
> But they are also logical, maintaining either alphabetical order, or the
> arbitrary order chosen for the models...
These should be part of the interface logic of your application, not
be an integral part of datamodel nor dataset.
> It looks like there is more than one way to skin a cat.
There are often too many, which makes the simple solution hidden.
"When facing the sunshine, you won't see the shadows" :)
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/
__________________________________________________
|
