OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: &


I am wondering if it might be worth taking a page from Paul Cotton's group
over at W3 XML Query, in light of both Sean and Rex's comments. The first
step that the group did was to not even worry about a formal XML Schema per
se, but rather to create a formal algebra for describing the space of
queries, then once this algebra was complete to create both XML and non-XML
implementations of the algebra. I talked with Paul at some length about why
they took this approach and he replied that there were any number of
different ideas for what each person wanted to have in the taxonomy but,
primarily because of the fairly strongly distrustful environment -- nobody
wanted to give up a point that would have been disadvantagous for their
business, even if it had benefits over-all, it was much more feasible to
explore what XML query was supposed to in a rigorous formalism, then address
one or more potential implementations once the algebra had been agreed to.

We're all trying to get a feel for what we think this should do; but are
letting our own preconceived notions get in the way. I, for instance,
believe that emotion description, while a useful capability, should not in
fact be a part of the core of HumanML, but should in fact be a module. My
reasoning for it is very simple -- look at the potential applications of
HumanML that have been laid out thus far. One of the most critical is as an
open source alternative to Passport, which is fundamentally an identity
schema. Passport has its roots in vCard, which Microsoft used as a means to
store business card information in Outlook. I think the structure of
Passport and vCard are both flawed, in great part because they were designed
in a very ad hoc fashion for easy access by certain Microsoft Office
products, not as a means to build a large, comprehensive framework of human
description or endeavor.

It seems reasonable to me to see an identity schema as a core, build an
extension mechanism into the schema early on, then start treating such
things as emotions, presence, preferences, etc., as first tier extensions.
We can employ a number of consistent conventions throughout -- the use of a
0 to 1 based intensity indicator, for instance, create a limited set of
attributes for handling structural interconnection information, choose a
specific set of nomenclature conventions, etc., but these are for the most
part stylistic issues.

I think we also have to be careful of discerning what is in the domain of
HumanML and what is not. Musicology is a fascinating area of discussion, but
is it something that specifically needs to be a part of HumanML? If it is,
then we should allocate an extension for building off of the core schema,
perhaps in an inheritance relationship of some sort:

class Musicology inherits HumanML {foobar}

or

class Musicology extends HumanML {foobar}

I know I'm bucking some of the work that has been done earlier, but my sense
of the direction of things at the moment is that we are trying to work at
too high a level. Just my two cents worth, and as I've said before, I'm
still trying to come to grips with the fairly significant amount of work
that has been done thus far. If we weren't, I honestly don't believe that
we'd be having these big exhortations about taxonomies of taxonomies, common
classes, and so forth. Just my two cents worth. I'll sit down and be quiet
now <grin/>.

-- Kurt



----- Original Message -----
From: "Rex Brooks" <rexb@starbourne.com>
To: "Sean B. Palmer" <sean@mysterylights.com>;
<humanmarkup-comment@lists.oasis-open.org>
Sent: Saturday, August 25, 2001 6:49 PM
Subject: Re: &


> I think any initiative is onto something when it draws the kind of
> ridicule you mention. There will always be these people, as there
> always have been. The world is flat and bumblebees and men can't fly.
>
> Ciao,
> Rex
>
> P.S. I think that the best way to answer criticism is simply to carry
> on with the work, get it done and move on.
>
> At 2:15 AM +0100 8/26/01, Sean B. Palmer wrote:
> >"Odd" was the word I was probably looking for. Whatever the post was, the
> >word was "odd".
> >
> >Len has been careful to explain to use the dangers in confuddling the
> >idioms, concepts, and abstract mechanisms that HumanMarkup introduces and
> >explores, with the HumanML interpretations, the instances, the class
> >diagrams, and the ambient technologies. But just as human communication
is
> >really only defined in every exchange of soul between two beings, so the
> >wonders of HumanMarkup will become manifest in the information space in
> >which we work.
> >
> >I find it hard to imagine such a project being conceived five years ago.
No
> >Semantic Web technologies, XML in its absolute infancy, metadata folk
still
> >arguing about what it means to title a book (well, they still are, we've
> >just learned to ignore them now), and so on. So I suggest that the "The
> >Source Code is the Specification" slogan applies, with all its
> >philosophical background, to HumanMarkup. I can't imagine how it could be
> >any other way. If we induldge ourselves in little "XML Schema vs. RELAXNG
> >vs. Schematron" debates, I think we can be forgiven.
> >
> >Keeping that in mind, I had an epiphany minora, in reading a fairly poor
> >article about HumanML [1] - Jim Dunn's "Ghost in the Machine" on iSource.
> >XML tree structures are 1.n dimensional, but communication modes aren't.
> >XML is no more useful to human communication than a condom is to a
> >Catholic. [I applaud those of you who are singing a certain Monty Python
> >song at this moment.] So it's lucky that we're not building XML here, or
> >even an XML language. We're building something less tangiable, but no
less
> >exciting: we're building a way of going about things, Kurt Cagle's
> >prophetic "taxonomy for taxonomies", Rex's insightful "*common*
packages",
> >Manos' wonderous "roots of the ontology tree" that we're not even going
to
> >charge for. My conclusion: the term "Markup/M" in "HumanMarkup/HumanML"
is
> >a terrible, and indeed damaging, misnomer.
> >
> >Consider the negative feedback that this group has recieved so far.
> >Emotions embedded in XML? Absurd, rediculous, laughable, and all the rest
> >of it. Consider the (actually pretty good) internet.com article entitled
> >"Working on a Unified Code for 'LOL' or :)" [2]. People must think that
> >we're a bunch of fucking idiots, or something. Lately, I have seen an
> >interesting reversal in this trend towards absurdity: mainly on this
list,
> >so perhaps I'm not looking hard enough, but people are starting to "get"
> >HumanMarkup, and once again, I submit that the only thing to "get" about
> >HumanMarkup is that there is no markup.
> >
> >Or is there? Now we get back to my little opening speech. The "taxonomy
of
> >taxonomies" *has* to become manifest in markup. The problem is that I
> >believe that the richness of the human communicative modes are too
> >wide-ranging to simply write out into a little graph and say, "here you
> >go". We're going to be coming up with idioms that require languages more
> >akin to OOP to do anything with. Functions cannot be embedded in XML.
They
> >can be represented, but not embedded. n-ary (not 3) relationships can't
be
> >embedded in RDF. They can be modelled very efficently, but not expressed
> >as-is. I remember a posting from Pat Hayes on the www-rdf-logic list
about
> >that some while ago, but can't be bothered to research the URI. I'll
leave
> >that as a task left to the interested reader.
> >
> >Which brings me to the next step in this little cavalcade of whimsy: the
> >hang up between documents and data. People are (aaargh!) thinking about
> >HumanML from a document standpoint. People on this list do the same
thing,
> >perhaps jokingly. Ranjeeth just did it, a few posts ago:-
> >
> >[[[
> ><suggestion>
> >Maybe we should eat our words, and write all our replies in XML.
> >Is this explicit enough?   </wink></smile>
> ></suggestion>
> >]]]
> >From: "Ranjeeth Kumar Thunga" <rkthunga@humanmarkup.org>
> >To: <humanmarkup-comment@lists.oasis-open.org>
> >Sent: Saturday, August 25, 2001 8:26 PM
> >Subject: Re: Brass Tacks #3
> >
> >He was joking (given by the fact that his XML wasn't even well-formed...
> ></wink> indeed; is that supposed to be a new form of empty tag, or
what?),
> >but others aren't. We need to dispell these myths right away: HumanML can
> >add no more value to XML than a few well placed words can. Indeed, to a
> >skilled writer, HumanML embedded in documentation could be a hinderance
> >rather than an advantage. XML is not magical; elements are only different
> >from words in that they can delimit sections. Stop thinking in terms of
> >documentation and elements, and think in terms of complex and cohesive
data
> >structures, manifest in huge databases of knowledge. Note how I'm
avioding
> >using the term "Semantic Web" here, but that would be the gist of it, if
> >there weren't an unbelievable amount of odd baggage attached to that term
> >too. Aha, "odd".
> >
> >So, what do I want? I want people to be very clear on what HumanMarkup is
> >and represents. It's not a human, and it's not markup :-) I want people
to
> >have no stupid delusions about what XML can and cannot do. XML can do
> >anything that any language can do, just not very efficiently [3]. I think
> >that the goal of HumanMarkup is to investigate just how far we can push
it.
> >That's no easy task, and perhaps I've been a bit too expectant in
thinking
> >that we'd develop any useful implementations. Perhaps we won't. That
isn't
> >the issue: the issue is that we're all here, working on this, learning,
> >contributing, experimenting, and pooling resources. The greatest threat
to
> >that isn't that we don't produce any useful implementations, and that
> >hasn't really been my point. It's that if HumanMarkup loses its *way*,
then
> >it becomes pointless. Implementations are just a measure of sticking to a
> >particular path.
> >
> >The greatest threat to HumanMarkup is misunderstanding, which is the
> >epitome of ironic, given that the goal of HumanMarkup is to reduce human
> >misunderstanding by increasing understanding. Now, you see this one-eyed
> >midget, shouting the word "now". And you say, "for what reason?", and
says
> >"how?". And you say, "what does this mean?", and he screams back, "you're
a
> >cow. Give me some milk, or else go home."
> >
> >Ah yes, "odd".
> >
> >[1] http://www.isourceonline.com/article.asp?article_id=1617
> >[2] http://www.internetnews.com/wd-news/article/0,,10_870221,00.html
> >[3] You think I'm joking? XSLT is Turing Complete, so XML has the same
> >amount of processing power as any computer language will *ever* be able
to
> >do, by conventional logic. But the turing completeness test is a pile of
> >rubbish, because it's very difficult to write Turing programs; viz. it's
> >difficult to get any level of abstraction to deal with what's going on.
> >
> >--
> >Kindest Regards,
> >Sean B. Palmer
> >@prefix : <http://webns.net/roughterms/> .
> >:Sean :hasHomepage <http://purl.org/net/sbp/> .
> >
> >
> >----------------------------------------------------------------
> >To subscribe or unsubscribe from this elist use the subscription
> >manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> --
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC