HoSML: History-of-Science Markup Language?
Jorn Barger
has been choosing a knowledge-domain that's rich enough to be
interesting without becoming too complex to model effectively.
My recent work with history-of-science timelines-- eg:
http://www.robotwisdom.com/science/natphils/
--makes me think this domain is about the right scale.
My immediate inspiration is an online database of scientist-
biographies that Richard Westfall has compiled, eg:
http://es.rice.edu/ES/humsoc/Galileo/Catalog/Files/fermat.html
Most scientific thought is communicated in books and journal-
articles. Tracing the history of science requires, in part,
tracing who-read-what-when. So if Westfall wanted to add a
little more AI to his database, he could create a class of
'publications' and identify, for each scientist, which
publications they wrote when, and which they read when.
You could then refine this by building an ontology of topics,
and identifying which topics were explored in each
publication, and when each scientist did their major research
on each topic.
A secondary ontology could model the mathematical toolkit
the scientists applied to these topics (eg, when did
Schroedinger first apply matrices to QM).
The availability of scientific instruments (eg telescopes)
is also important, so you'd want classes for these, and
representations of who invented them, improved them, bought
and sold them, etc.
The notation I'm picturing is exactly like my Internet
Timelines Project: http://www.robotwisdom.com/web/biography.html
ian glendinning
> Tracing the history of science requires, in part,
> tracing who-read-what-when.
I say "who read what", is a bit difficult to prove except by
inference. As you know I'm no supporter of scientific evidence, but
what i believe in is "who cites who" because it's more directly
objective.
Ian Davis
> The notation I'm picturing is exactly like my Internet
> Timelines Project: http://www.robotwisdom.com/web/biography.html
Linking Project:
http://heml.mta.ca/heml-cocoon/
--
Ian Davis
http://InternetAlchemy.org
Jorn Barger
> > The notation I'm picturing is exactly like my Internet
> > Timelines Project: http://www.robotwisdom.com/web/biography.html
> Linking Project: http://heml.mta.ca/heml-cocoon/
Yikes-- that's depressing.
Somewhere along TimBL's yellow brick road to the Semantic Web,
everybody seems to have forgotten what a document is, and
have chosen to create databases instead.
Here's what you have to learn to designate a date in HEML:
BoundedDate
ChronologicalRelationship
Chronology
ComplexDate
DateRange
EndingDate
IntCalDate (integer calendar?)
IntCalDay
IntCalendar
IntCalEra
IntCalMonth
IntCalYear
PossibleChronologicalRelationships
StartingDate
TerminusAnteQuem
TerminusPostQuem
XMLSchemaDate
XMLSchemaGYear
DatePrimitivesGroup
PossibleDatesGroup
UncertainDateGroup
No author creating a webpage is going to bother with those
for every damn date they type in!
My approach is to use 'fake' XML (I suggested it be called
XHTML, but that name was immediately hijacked for more
nefarious purposes), with one tag for each historical event,
and within that tag many HEML-like attributes that spell out
the nature of the event.
The initial design-flaw of XML was what I call "Goldfarb's
conjecture"-- the untested hypothesis that document layout
derives from structural or semantic categories that are
more fundamental than the 'superficial' styles.
What happens when a True Believer tries to use this to do
semantic representation is just what you see in these HEML
examples-- spectacularly bloated files that must have been
excruciatingly annoying to create, and are excruciatingly
annoying to try and use.
Bruce Robertson
> Ian Davis <ia...@InternetAlchemy.org> wrote in message news:<70aa8be4.03041...@posting.google.com>:
> > > The notation I'm picturing is exactly like my Internet
> > > Timelines Project: http://www.robotwisdom.com/web/biography.html
> > You may also be interested in the Historical Event Markup and
> > Linking Project: http://heml.mta.ca/heml-cocoon/
>
> Yikes-- that's depressing.
>
> Somewhere along TimBL's yellow brick road to the Semantic Web,
> everybody seems to have forgotten what a document is, and
> have chosen to create databases instead.
>
> Here's what you have to learn to designate a date in HEML:
>
> BoundedDate
> ChronologicalRelationship
> Chronology
> ComplexDate
> DateRange
> EndingDate
> IntCalDate (integer calendar?)
> IntCalDay
> IntCalendar
> IntCalEra
> IntCalMonth
> IntCalYear
> StartingDate
> TerminusAnteQuem
> TerminusPostQuem
> XMLSchemaDate
> XMLSchemaGYear
* PossibleDatesGroup
* UncertainDateGroup
>
> No author creating a webpage is going to bother with those
> for every damn date they type in!
>
I'm the director of Heml, and while I'll cheer on Jorn in his quest to
markup biographical info, I must correct the info above because it
inaccurately implies that our markup is terribly hard to use and
crufty.
I'll address this in the points below:
1. The above list includes every element in the Heml schema that
somehow relates to chronology. Some are 'container' schema elements
that will never appear in a conforming document. (I've marked them
with a '*' above.) Others are for marking up events in non-Gregorian
calendars, such as the Japanese one. (Yes Heml can convert from/to a
healthy list of these, thanks to IBM's International Calendars for
Java.) Others strive to express some complex chronological relations
or kinds of uncertainty that historians (especially ancient historians
like myself) find important.
2. Consequently, a person using an in-context XML editor like XMLSpy
or the increasingly useful jedit will find a small and quite
comprehendable list of possible elements at each juncture. I have
observed many students using the Schema with XMLSpy. None of these had
any previous XML experience; they all caught on to the chronology
markup they needed to use in a matter of minutes.
(The automatically generated schema documentation does, however, refer
to all of the elements above. That's probably what caused the
confusion. But drawing that conclusion is a bit like saying that
Docbook is byzantine because it has a complex DTD.)
3. Jorn's site's examples of a single date or a date range are pretty
simple in Heml, too:
<heml:Chronology>
<heml:XMLSchemaDate>1966-12-18</heml:XMLSchemaDate>
</heml:Chronology>
and
<heml:Chronology>
<heml:DateRange>
<heml:StartingDate>
<heml:XMLSchemaDate>1964-12-03</heml:XMLSchemaDate>
</heml:StartingDate>
<heml:EndingDate>
<heml:XMLSchemaDate>1966-12-18</heml:XMLSchemaDate>
</heml:EndingDate>
</heml:DateRange>
</heml:Chronlogy>
> My approach is to use 'fake' XML (I suggested it be called
> XHTML, but that name was immediately hijacked for more
> nefarious purposes), with one tag for each historical event,
> and within that tag many HEML-like attributes that spell out
> the nature of the event.
>
That's quite sensible, since you don't anticipate internationalizing
the textual bits (such as personal names) nor do you intend to
associate your events with multiple primary documents (in print and on
the internet) that assert or mention them. Heml provides the latter
facilities because students of history tend to be hung up on things
like that.
> The initial design-flaw of XML was what I call "Goldfarb's
> conjecture"-- the untested hypothesis that document layout
> derives from structural or semantic categories that are
> more fundamental than the 'superficial' styles.
>
> What happens when a True Believer tries to use this to do
> semantic representation is just what you see in these HEML
> examples-- spectacularly bloated files that must have been
> excruciatingly annoying to create, and are excruciatingly
> annoying to try and use.
See above on how excruciating, or not, Heml-conforming documents are
to make. As for bloat, the list of chronological elements above should
not be considered evidence of that. OTOH Heml element names are quite
verbose, by design. It is hoped that the nested structure and lack of
abbreviations will make the Heml document as self-documenting as
possible. I would imagine, for example, that the intent of my second
example above is clearer than Jorn's condensed "time1='1894.10'
time2='1896.4'" And *both* schemes are miles more condensed and
intelligible than the world of RDF and TopicMaps, where I imagine this
material will eventually go.
More accurately, I would say that we have different goals: Jorn's is
concision, working in a modern Gregorian context; ours, historical
universality, as is possible. That necessarily entails a larger
toolkit; but it doesn't mean one has to understand all of the tools
before using the markup schema for her purposes.
I encourage the readers of these lists to examine the conforming
documents for themselves. For exmaples, an outline of the life of
Bacon at:
http://heml.mta.ca/heml-cocoon/source.html?url=docs/source/heml/bacon.xml
or an English/Bulgarian/Russian document pertaining to the Russian
Revolution, available from CVS:
http://heml.mta.ca/cgi-bin/viewcvs.cgi/heml_cvs/web/docs/source/heml/russia_post_rev.xml
I'd very much appreciate any further criticism.
(In point of fact, I imagine the toolkit will grow, as a
next-generation Heml schema imports the Geographical Markup Language
to replace heml:Location and a simple profile of TimeML to replace
heml:Chronology. I'd rather leave that stuff up to experts in their
fields.)
In case this thread hasn't made it clear, I should add that Heml
markup 'does stuff' right now. An Open Source webapp transforms
conforming documents into SVG/jpg timelines, maps and animated maps
(as well as more humble html views.) Sample transformations, like an
animated map of events in ancient Greek medicine, are available from
the project homepage: http://heml.mta.ca
Finally, like Jorn's envisages for his markup, Heml documents can be
combined across the web, as discussed in my paper at ACH/ALLC 2002:
http://www.uni-tuebingen.de/cgi-bin/abs/abs?propid=102
In the end, though, XSLT makes all things possible. Once you devise a
History-of-Science Markup Language (if you feel such a thing is
necessary), we could write a quick 'sheet to upcast your markup to
Heml, pop the result on the server, and get the creativity flowing by
seeing how it looks in Heml maps, timelines, etc.
All the best,
Bruce Robertson
Dept. of Classics, Mount Allison University
http://heml.mta.ca
Jorn Barger
> > > > The notation I'm picturing is exactly like my Internet
> > > > Timelines Project: http://www.robotwisdom.com/web/biography.html
> > > You may also be interested in the Historical Event Markup and
> > > Linking Project: http://heml.mta.ca/heml-cocoon/
> quest to mark up biographical info
If you're deducing that from the url, you're mistaken-- my
timelines are not specifically biographical, eg:
http://www.robotwisdom.com/science/natphils/
> [...] Others are for marking up events in non-Gregorian
> calendars, such as the Japanese one.
I certainly appreciate the idealism here, but I think the result
is very symptomatic of misguided AI-- an enormous effort is put
into busywork on the comparatively easy and superficial problems
of building tools, but the hard semantic problems never seem to
get addressed at all.
By the time you've buried the _simple_ parts of your data in
this much complexity, you simply can't see the important parts
with any clarity.
> Others strive to express some complex chronological relations
> or kinds of uncertainty that historians (especially ancient
> historians like myself) find important.
I'm also conscious of those subtleties, via both ancient-
history timelines and original work with Joyce's notebooks.
It's a very delicate design-imperative to hide the
complexities since most users won't ever dig that deep.
> 2. Consequently, a person using an in-context XML editor like XMLSpy
> or the increasingly useful jedit will find a small and quite
> comprehendable list of possible elements at each juncture. I have
> observed many students using the Schema with XMLSpy. None of these had
> any previous XML experience; they all caught on to the chronology
> markup they needed to use in a matter of minutes.
A fancy data-entry system may be fun for a certain type of
author for a certain period of time, but I predict that
when they start trying to do real history, it will *get in
the way*.
> (The automatically generated schema documentation does, however, refer
> to all of the elements above. That's probably what caused the
> confusion. But drawing that conclusion is a bit like saying that
> Docbook is byzantine because it has a complex DTD.)
Everything I've seen of Docbook was repellantly byzantine.
> 3. Jorn's site's examples of a single date or a date range are pretty
> simple in Heml, too:
>
> <heml:Chronology>
> <heml:XMLSchemaDate>1966-12-18</heml:XMLSchemaDate>
> </heml:Chronology>
Q1: Have you omitted an attribute that restates the date in
standard form, or does the parser work it out?
Q2: In a prose work (as opposed to a database) if I'm
already talking about December 1966 and I want to write,
"Then on the 18th..." or "The following Thursday..." how do
you handle this?
Q3: Isn't the whole notion of tagging individual semantic
items inappropriately bloated/tedious/inefficient when a
parser could do it better?
Q4: Eg, when you tag a person's name, do you re-tag every
occurrence? (Your Bacon 'timeline' demo does.)
> > My approach is to use 'fake' XML (I suggested it be called
> > XHTML, but that name was immediately hijacked for more
> > nefarious purposes), with one tag for each historical event,
> > and within that tag many HEML-like attributes that spell out
> > the nature of the event.
>
> That's quite sensible, since you don't anticipate internationalizing
> the textual bits (such as personal names)
You're not authoring your texts... you're embalming them!
> nor do you intend to
> associate your events with multiple primary documents (in print and on
> the internet) that assert or mention them.
In fact, my design-theory for timelines aims for one or more
links per entry, eg: http://www.robotwisdom.com/ai/timeline/1600.html
> [...] Heml element names are quite
> verbose, by design. It is hoped that the nested structure and lack of
> abbreviations will make the Heml document as self-documenting as
> possible.
If you said "...the Heml database..." then I'd agree, but
documents are already required to be self-documenting to the
*reader*, without viewing the source.
> I would imagine, for example, that the intent of my second
> example above is clearer than Jorn's condensed "time1='1894.10'
> time2='1896.4'"
No way. There's such a thing as over-explaining.
> And *both* schemes are miles more condensed and
> intelligible than the world of RDF and TopicMaps, where I imagine this
> material will eventually go.
Stop, you're scaring me.
Topic maps are a good approach to semantic research, but if
the implementation is expected to be bloatier than Heml,
something is seriously askew.
> More accurately, I would say that we have different goals: Jorn's is
> concision, working in a modern Gregorian context;
No, mine is practicality.
> ours, historical universality, as is possible.
Yes-- you remind me of the Egyptian pharaohs hoping for
immortality via mummification. I've no doubt that the plan
also involves huge grants to pay data-entry peons, because
expecting authors to mummify their own efforts is wildly
unrealistic. (I've been over a lot of this ground wrt the
Perseus Project: http://www.robotwisdom.com/sites/perseus.html )
> That necessarily entails a larger
> toolkit; but it doesn't mean one has to understand all of the tools
> before using the markup schema for her purposes.
My original post dealt with publications and scientific
instruments-- do you have ambitions in that direction?
> I encourage the readers of these lists to examine the conforming
> documents for themselves. For exmaples, an outline of the life of
> Bacon at:
> http://heml.mta.ca/heml-cocoon/source.html?url=docs/source/heml/bacon.xml
Do you have anything non-trivial? (The information-density of
the examples I saw was about 5% of my own timelines, and the
total quantity of info about 0.01%)
> (In point of fact, I imagine the toolkit will grow, as a
> next-generation Heml schema imports the Geographical Markup Language
> to replace heml:Location and a simple profile of TimeML to replace
> heml:Chronology. I'd rather leave that stuff up to experts in their
> fields.)
The fallacy here is that people are creating tools and
expecting the content to follow, but until people try to
make something greater than toy demos, they can't possibly
appreciate how poorly thought-out the tools are.
> In case this thread hasn't made it clear, I should add that Heml
> markup 'does stuff' right now. An Open Source webapp transforms
> conforming documents into SVG/jpg timelines, maps and animated maps
> (as well as more humble html views.) Sample transformations, like an
> animated map of events in ancient Greek medicine, are available from
> the project homepage: http://heml.mta.ca
Sorry, those are still toy demos. You won't understand the
design problems until you try making something genuinely
useful, that has to compete with simpler technologies.
> Finally, like Jorn's envisages for his markup, Heml documents can be
> combined across the web, as discussed in my paper at ACH/ALLC 2002:
> http://www.uni-tuebingen.de/cgi-bin/abs/abs?propid=102
Way too much jargon for me-- can you restate it in English?
> In the end, though, XSLT makes all things possible.
That, and a quart of snake-oil.
> Once you devise a
> History-of-Science Markup Language (if you feel such a thing is
> necessary), we could write a quick 'sheet to upcast your markup to
> Heml,
No, since I only tag whole events, you'd have to do
sophisticated parsing to break my attributes out into
your elements.
> pop the result on the server, and get the creativity flowing by
> seeing how it looks in Heml maps, timelines, etc.
If your creativity is driven by your tools, you're not
a real historian.
--
"There's no better reader on the Internet than Jorn Barger"
--The Register
Robot Wisdom Weblog: http://www.robotwisdom.com/
John Harper
But it's possible to cite something without having read it,
and it's possible to get material from somewhere and cite something
else which contains the same material and which one has also read.
John Harper, School of Mathematical and Computing Sciences,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Bruce Robertson
news:<62fdfd04.0304...@posting.google.com>...
> > > > > The notation I'm picturing is exactly like my Internet
> > > > > Timelines Project: http://www.robotwisdom.com/web/biography.html
> > > > You may also be interested in the Historical Event Markup and
> > > > Linking Project: http://heml.mta.ca/heml-cocoon/
> > I'm the director of Heml, and while I'll cheer on Jorn in his
> > quest to mark up biographical info
>
Responses correcting misconceptions and answering questions follow:
> > [...] Others are for marking up events in non-Gregorian
> > calendars, such as the Japanese one.
>
> I certainly appreciate the idealism here, but I think the result
> is very symptomatic of misguided AI-- an enormous effort is put
> into busywork on the comparatively easy and superficial problems
> of building tools, but the hard semantic problems never seem to
> get addressed at all.
>
For what it is worth, I don't consider Heml an AI project any more
than theTEI or Epidoc are. It's marked-up data in, churn, churn, SVG
timeline out. I can imagine an AI project making use of this data for
their own, morecomputationally advanced, purposes.
As for our building these transformational tools alongside the markup,
this was part of the original proposal, and aimed to ensure that we
didn't build some sort of markup nirvana which encoded historical
events beautifully, but for which no tools existed.
The multi-calendrical qualities of Heml (which, as I've mentioned, the
modernist need not enter into) are not accurately characterized as
idealism: they work, people use them.
> By the time you've buried the _simple_ parts of your data in
> this much complexity, you simply can't see the important parts
> with any clarity.
>
At conferences and on-line, I continue to solicit expert advise on
how to simplify our schema while expressing the information we need
(keywords, geotemporal stuff, persons, etc.) in a multi-lingual and
multi-calendrical way. I also think there are a bazillion ways to skin
this particular cat, and many paths between those ways, xslt being the
easiest (see below).
> > Others strive to express some complex chronological relations
> > or kinds of uncertainty that historians (especially ancient
> > historians like myself) find important.
>
> I'm also conscious of those subtleties, via both ancient-
> history timelines and original work with Joyce's notebooks.
> It's a very delicate design-imperative to hide the
> complexities since most users won't ever dig that deep.
>
I can't seem to find the markup for these projects online. It, and any
accompanying schema, would be of great interest to me and others.
> > 2. Consequently, a person using an in-context XML editor like XMLSpy
> > or the increasingly useful jedit will find a small and quite
> > comprehensible list of possible elements at each juncture. I have
> > observed many students using the Schema with XMLSpy. None of these had
> > any previous XML experience; they all caught on to the chronology
> > markup they needed to use in a matter of minutes.
>
> A fancy data-entry system may be fun for a certain type of
> author for a certain period of time, but I predict that
> when they start trying to do real history, it will *get in
> the way*.
>
jedit is a text editor with plugins, among them XML element completion
and XML Schema validation on save. This is why we write schemas or
DTDs, so that these common tools are available to our users. As for
me, I just use vi, but then I wrote the schema, didn't I?
> > (The automatically generated schema documentation does, however, refer
> > to all of the elements above. That's probably what caused the
> > confusion. But drawing that conclusion is a bit like saying that
> > Docbook is byzantine because it has a complex DTD.)
>
> Everything I've seen of Docbook was repellantly byzantine.
>
> > 3. Jorn's site's examples of a single date or a date range are pretty
> > simple in Heml, too:
> >
> > <heml:Chronology>
> > <heml:XMLSchemaDate>1966-12-18</heml:XMLSchemaDate>
> > </heml:Chronology>
>
> Q1: Have you omitted an attribute that restates the date in
> standard form, or does the parser work it out?
No, that *is* the standard form, according to the XML Schema spec:
http://www.w3c.org/TR/xmlschema-2/#date
All Gregorian time primitives in Heml use the XML Schema ones. This
means that a XML schema aware editor can check for conformity on
data-entry, or a validator on validation. This blocks a whole raft of
errors compared to the PCDATA approach, and I'd recommend it when
HoSML comes to defining its schema, though I'd look into RelaxNG as
the schema language.
>
> Q2: In a prose work (as opposed to a database) if I'm
> already talking about December 1966 and I want to write,
> "Then on the 18th..." or "The following Thursday..." how do
> you handle this?
>
If one is embedding heml:Event elements in xhtml using our xhtml+heml
schema (which is more in the spirit of your 'XHTML' idea), then the
Heml data should be considered editorial -- embedded metadata, perhaps
-- not as something that exposes the meaning of the text as it stands.
There are any number of tools that allow you to declare a string like
'the following Thursday' as a chronological marker, and really smart
people are working on hauling that out into a chronological framework.
TimeML folks in particular.
The Heml approach is more simple: one explicitly converts strings like
'the following Thursday' into dates, days, year, etc. Heml can be
understood as the electronic equivalent of an historical commentary.
> Q3: Isn't the whole notion of tagging individual semantic
> items inappropriately bloated/tedious/inefficient when a
> parser could do it better?
>
I'm looking forward to results from the research mentioned above that
might make such parsing possible. (Niccoluci, a co-researcher on Heml,
and his group have had some success in this sort of thing.) But I fear
that it will be a long time before it can be applied equally well to
demotic papyri as to modern-day newspaper items in English.
Furthermore, once such parsing is done, we might want to view the
results as maps and timelines, in which case something like the Heml
webapp would be helpful, and Heml markup treated as an intermediary
data-format.
> Q4: Eg, when you tag a person's name, do you re-tag every
> occurrence? (Your Bacon 'timeline' demo does.)
>
One occurrence in the document (typically the first) defines the
person with a <heml:Person id="ben_franklin">....</heml:Person>
element. Subsequent references to this person are made with
<heml:PersonRef idref="ben_franklin"/>. Again, this means that
identities and cross-references are checked at the time of validation.
heml:Foo / heml:FooRef is a design pattern used throughout: for
locations, roles, keywords, etc.
> > > My approach is to use 'fake' XML (I suggested it be called
> > > XHTML, but that name was immediately hijacked for more
> > > nefarious purposes), with one tag for each historical event,
> > > and within that tag many HEML-like attributes that spell out
> > > the nature of the event.
>
> In fact, my design-theory for timelines aims for one or more
> links per entry, eg: http://www.robotwisdom.com/ai/timeline/1600.html
>
Again, the XML (or 'fake XML', as you describe it) underlying the
above, would be great to poke around inside.
> > [...] Heml element names are quite
> > verbose, by design. It is hoped that the nested structure and lack of
> > abbreviations will make the Heml document as self-documenting as
> > possible.
>
> If you said "...the Heml database..." then I'd agree, but
> documents are already required to be self-documenting to the
> *reader*, without viewing the source.
>
Here I think I've found a source of misunderstanding in XML jargon. By
'document', we mean the xml document, as you see in our examples. In a
similar spirit, we could refer to the XML output of Gnumeric as a
'document'. (The relations between XML documents [in this sense] and
relational databases are well-defined, and I would therefore shy away
from calling Heml documents, of whatever scope, a database.) Another
meaning of 'document' is the kind we read: a novel or the deed to a
property. With respect to these, I would agree to your stipulation.
> Yes-- you remind me of the Egyptian pharaohs hoping for
> immortality via mummification. I've no doubt that the plan
> also involves huge grants to pay data-entry peons, because
> expecting authors to mummify their own efforts is wildly
> unrealistic. (I've been over a lot of this ground wrt the
> Perseus Project: http://www.robotwisdom.com/sites/perseus.html )
>
I'm happy to say that some of the documents featured on heml.mta.ca
are made by amateurs, not mercenaries, inside my university and from
elsewhere.
> > That necessarily entails a larger
> > toolkit; but it doesn't mean one has to understand all of the tools
> > before using the markup schema for her purposes.
>
> My original post dealt with publications and scientific
> instruments-- do you have ambitions in that direction?
>
No. That is too domain-specific. Is it possible to extend basic Heml
markup to include project-specific markup? Yes: that's what the
Virginia Center for Digital History is doing on the Runaway Slaves
Project.
> > I encourage the readers of these lists to examine the conforming
> > documents for themselves. For examples, an outline of the life of
> > Bacon at:
> > http://heml.mta.ca/heml-cocoon/source.html?url=docs/source/heml/bacon.xml
>
> Do you have anything non-trivial? (The information-density of
> the examples I saw was about 5% of my own timelines, and the
> total quantity of info about 0.01%)
I suspect the 'information-density' stats will always be
disappointing, since, as I mentioned in the previous post, verbose,
self-documenting markup was a goal. As for sheer number of events
marked-up, our summer work with VCDH should provide events a'plenty
:-)
In any case, I admire the volume of material on robotwisdom.com and
will be sure to let my colleagues know about it.
> > In case this thread hasn't made it clear, I should add that Heml
> > markup 'does stuff' right now. An Open Source webapp transforms
> > conforming documents into SVG/jpg timelines, maps and animated maps
> > (as well as more humble html views.) Sample transformations, like an
> > animated map of events in ancient Greek medicine, are available from
> > the project homepage: http://heml.mta.ca
>
> Sorry, those are still toy demos. You won't understand the
> design problems until you try making something genuinely
> useful, that has to compete with simpler technologies.
Students at this university using and developing those documents for
their study of history and philosophy don't, as far as I can tell,
consider them 'toy demos'. The ACH/ALLC paper mentioned above shows
how the smaller documents, say the life of Bacon, can be integrated
together to make larger and larger ones, such as the 'Modern
Philosophers' document on our site, comprising the lives of Bacon,
Hume, Descartes, Spinoza, etc. (This is somewhat tricky because two
documents might use a different id strings, say id="ben_franklin and
id="bf", and a steering document has to say which takes charge and
what equals what.)
I'm not sure I understand the notion of 'competition' here. Heml is an
Open Source project, and its data is freely available. Data conforming
to a simpler schema can be translated to it, if it makes sense to do
so. Domain-specific data could also be translated, if the price in
information-loss is worth the gains.
> > Once you devise a
> > History-of-Science Markup Language (if you feel such a thing is
> > necessary), we could write a quick 'sheet to upcast your markup to
> > Heml,
>
> No, since I only tag whole events, you'd have to do
> sophisticated parsing to break my attributes out into
> your elements.
I was drawing my conclusions on the markup fragments at
http://www.robotwisdom.com/web/biography.html If that's the basic
idea, ITPML -> HEML is a piece of cake with xslt. (There must be
something more to it, though, since you say above that you want to
have multiple links off an event. Seems tricky to have an arbitrarily
large number of these if you're going to stick to attributes.)
All the best,
Jorn Barger
> For what it is worth, I don't consider Heml an AI project any more
> than theTEI or Epidoc are.
If it involves knowledge-representation, it's AI.
> As for our building these transformational tools alongside the markup,
> this was part of the original proposal, and aimed to ensure that we
> didn't build some sort of markup nirvana which encoded historical
> events beautifully, but for which no tools existed.
A beautiful encoding shouldn't need tools to prove itself. But
my concern isn't that the encoding is flawed, it's that the tools
will be hard to use and the resulting databases/documents will
be too clumsy.
> The multi-calendrical qualities of Heml (which, as I've mentioned, the
> modernist need not enter into) are not accurately characterized as
> idealism: they work, people use them.
People use SGML too, but it's excruciatingly painful, so proposing
it as a general solution for the Web would be absurdly idealistic.
> [...] I also think there are a bazillion ways to skin
> this particular cat, and many paths between those ways, xslt being the
> easiest (see below).
Below where?
> > I'm also conscious of those subtleties, via both ancient-
> > history timelines and original work with Joyce's notebooks.
>
> I can't seem to find the markup for these projects online. It, and any
> accompanying schema, would be of great interest to me and others.
An example of the problems with ambiguous chronology:
http://www.robotwisdom.com/jaj/fwake/stratig.html
But I'm trying to take one step at a time, and test it before going
further. For me, the priority for timelines-markup is getting
a central registry for celebrity-names going. The first _use_
for the registry would probably be in META headers, where I think
most semantic markup belongs. (META headers should also include
Yahoo and/or DMoz categories, and a content-type classification.)
> > > <heml:Chronology>
> > > <heml:XMLSchemaDate>1966-12-18</heml:XMLSchemaDate>
> > > </heml:Chronology>
> >
> > Q1: Have you omitted an attribute that restates the date in
> > standard form, or does the parser work it out?
>
> No, that *is* the standard form, according to the XML Schema spec:
> http://www.w3c.org/TR/xmlschema-2/#date
Fine, for databases. But for documents, the W3C has no right to
dictate how I express dates.
> {...] when HoSML comes to defining its schema
Not a willing candidate for mummification, sorry.
> I'm looking forward to results from the research mentioned above that
> might make such parsing possible. [...] But I fear
> that it will be a long time before it can be applied equally well to
> demotic papyri as to modern-day newspaper items in English.
Who are you imagining will use Heml for newspaper articles?
Surely not the newspapers themselves? The problem I'm
addressing with ITP is 'synchronising' multiple Web timelines--
if the markup dramatically slows down creation or consumption of
my pages, then it's not really usable.
This implies that tagging individual dates/names/places/etc is
overkill-- my minimalist compromise is to tag whole 'events'
and list dates/persons/etc as attributes. The authoring tool
can make a stab at guessing them, so the author just has to
correct its mistakes.
> One occurrence in the document (typically the first) defines the
> person with a <heml:Person id="ben_franklin">....</heml:Person>
> element. Subsequent references to this person are made with
> <heml:PersonRef idref="ben_franklin"/>.
But since most of these will never ever be needed, and since
generating them later with a parser is mostly trivial (look
for 'Ben', look for 'Franklin', look for 'he' following Ben
or Franklin), weighting the document with all that bloat is
a waste of the author's effort.
> > In fact, my design-theory for timelines aims for one or more
> > links per entry, eg: http://www.robotwisdom.com/ai/timeline/1600.html
>
> Again, the XML (or 'fake XML', as you describe it) underlying the
> above, would be great to poke around inside.
It's just what I showed on my biography.html page. The links
don't need to be attributes, they're plain old <A>s.
> (The relations between XML documents [in this sense] and
> relational databases are well-defined, and I would therefore shy away
> from calling Heml documents, of whatever scope, a database.)
Not all databases are relational.
> Another
> meaning of 'document' is the kind we read: a novel or the deed to a
> property. With respect to these, I would agree to your stipulation.
So you don't intend Heml to be used for reading-documents???
> I'm happy to say that some of the documents featured on heml.mta.ca
> are made by amateurs, not mercenaries, inside my university and from
> elsewhere.
Well the Perseus Project has spent millions of dollars in grant
money mummifying the classics, and the results ain't pretty.
You can tell from the uncorrected typos and design flaws that
it's _not_ a labor of love, it's a mechanism for gratifying
egos.
The great power of the Web is that individual enthusiasts can
contribute on a level playing field. Any project that tries
to turn this into ego-mummification is doomed to fail.
> Is it possible to extend basic Heml
> markup to include project-specific markup? Yes: that's what the
> Virginia Center for Digital History is doing on the Runaway Slaves
> Project.
Since it's just a database, I guess I have no problem with your
using XML/Heml. (But if you're still arguing that its XML can be
extended to what I call documents, I do have problems.)
> Students at this university using and developing those documents for
> their study of history and philosophy don't, as far as I can tell,
> consider them 'toy demos'. The ACH/ALLC paper mentioned above shows
> how the smaller documents, say the life of Bacon, can be integrated
> together to make larger and larger ones, such as the 'Modern
> Philosophers' document on our site, comprising the lives of Bacon,
> Hume, Descartes, Spinoza, etc.
Input 100 timeline-events for each philosopher, with overlaps where
they influenced each other, and synchronise these with a tool, and
then I'll be impressed. But I think your inputters will rebel
unless they're being paid (and probably even if they are).
> (This is somewhat tricky because two
> documents might use a different id strings, say id="ben_franklin and
> id="bf", and a steering document has to say which takes charge and
> what equals what.)
I've proposed a central registry, plus local abbreviations.
> I'm not sure I understand the notion of 'competition' here.
On the Web, every page is in competition with every other page,
or more specifically with every page offering similar info.
This means, eg, that when I'm looking for an etext of a classic,
and Google offers me Bibliomania's copy or MIT's copy, I'll
normally go with MIT because Bibliomania has annoying popups.
Similarly, if I have the choice between an animated map or a
messy jpeg or a simple and clear gif, I'll usually go with the
gif.
> I was drawing my conclusions on the markup fragments at
> http://www.robotwisdom.com/web/biography.html If that's the basic
> idea, ITPML -> HEML is a piece of cake with xslt.
But not pulling my 'date1' attribute out of the event tag, and
wrapping it around the actual date in my document-text-- that
would take parsing.
Bruce Robertson
> > For what it is worth, I don't consider Heml an AI project any more
> > than theTEI or Epidoc are.
>
> If it involves knowledge-representation, it's AI.
Though this discussion has been quite interesting, I think now that
I've managed to represent what Heml is about, I should stop
interloping on these newsgroups.
Thanks for your time and your spirited dialogue, Jorn.
Yrs,
Bruce Robertson
Dept. of Classics Mount Allison University
http://heml.mta.ca
Jorn Barger
> the scientists applied to these topics (eg, when did
> Schroedinger first apply matrices to QM).
A related idea that I've been exploring is a Philosophy
Markup Language (PhML) that restates (or caricatures)
classical philosophical theories in terms of object-
oriented design. Eg, Aristotle's theory of motion divides
the world into various classes of entity, each of which
has a slot for 'natural motions'.
The mechanistic worldview (Descartes et seq) rejected
this slot and instead declared that all material entities
are composed of dumb atoms, and that all atoms have the
same set of natural motions.
So the HoSML would need to be able to represent each of
these alternatives, and also each of the stages by which
the one replaced the other. (Eg Galileo explored whether
atoms of a marble column could be held together by the
same force of vacuum that water-pumps used, and concluded
they could not-- some other 'natural motion' of atoms was
needed.)
Jorn Barger
[regarding historical theories of motion]
> [...] HoSML would need to be able to represent each of
> these alternatives, and also each of the stages by which
> the one replaced the other.
A much more general application of 'object-oriented' history-
of-science is the attempt to analyse a domain-- any domain--
into categories.
An HoSML representation of this would identify the scientist
and the date, the domain, and the _list_ of categories
proposed. My long timeline of knowledge representation--
http://www.robotwisdom.com/ai/timeline/0000.html
http://www.robotwisdom.com/ai/timeline/1600.html
http://www.robotwisdom.com/ai/timeline/1938.html
http://www.robotwisdom.com/ai/timeline/1970.html
--singles out hundreds of such categorisation-events and
includes the lists themselves, which I've never seen
done before.
One of these is even marginally self-referential:
1987: Ellis's taxonomy of information behavior:
starting, chaining, browsing, differentiating,
monitoring, extracting, verifying, ending
cite: http://citeseer.nj.nec.com/wilson00human.html
(I'm guessing that 'differentiating' would include
'categorising' though I haven't read the paper.)