Hi.
As far as I understand it, topic maps match what you describe below in
significant ways.
It would allow for the dynamic merging you describe in the first
paragraph (quoted below), though at this time the implementations lag
far behind those in the relational world in terms of maturity and
standardization.
From your second paragraph (below) topic maps use hierarchical documents
to represent graph structures as you describe. In the topic maps
paradigm you wouldn't usually "reference [an] embedded relationship
graph from the primary document" unless I misunderstand your meaning in
this.
The third paragraph could be describing topic maps verbatim if you cut
off everything from the first mention of css onward.

>Nathan
the database side we store our relationships in a graph structures
(which I've talked about on the list at times). At the moment we end
up dynamically creating separate documents that summarise our
relationships on a document context by document context basis. Any
given final result document ends up getting created dynamically (via
XSLT) to reflect the merging of some initial document with some set of
discovered links. From our side of the world this meets many of the
requirements you list, however, it is pretty much useless across
multiple domains.
I could see creating a standard that encapsulates the essentials of
this approach. In particular, using the hierarchical structure of XML
to create document sections that give relationships with graph
structures being reflected via multiple such hierarchies. Existing
mechanisms could then reference this embedded relationship graph from
the primary document. In our case we use element names and name spaces
to match up the relationships with the document nodes which allows for
many to many relationship mapping but also leaves some room for
ambiguity.
If I was going to go whole hog on this approach I'd probably end up
with some document format that allowed for multiple document roots
with each root level having some content type declaration. This way
one could ship a single data instance containing well separated
sections containing the primary document, the relationship graphs, any
CSS, any XSLT, etc. I'd probably use MIME type section identifiers
instead of PI type identifiers so that things like the CSS and (ahem)
binary XML could be easily packaged up, so this isn't so much an XML
2.0 as it is a HTTP 3.0 data envelope, but I digress as this has only
a little to do with the problem at hand

Hi,

Le vendredi 22 septembre 2006 11:09 -0700, Nathan Young -X (natyoung -
Artizen at Cisco) a :
Hi.

As far as I understand it, topic maps match what you describe below in
significant ways.

Topic Maps are often mentioned as a XLink success story and that's the
second time they are coming quoted in this thread and that'll give me
the opportunity to express a point that's been bothering me for a while.

I am not really a Topic Maps expert and most of what I know about Topic
Maps has been acquired sitting in discussions between RDF and TM geeks.

of the thing which kept popping up is that TM are about defining
links with multiple arcs and this is the domain of extended XLinks.
However, XTM has chosen, for the sake of simplicity, to use simple links
rather than extended links.

As far as I remember, the XLink recommendation sees the other way round
and sees simple links as a specific case of extended links

Using XLink to simulate extended links with a bunch of simple links
looks to me like saying: "K; we'll take the syntax so that we can say
we are compliant but we'll attach a slightly different meaning".

If I am right, XTM can hardly pretend to be using XLink :)

TH, if I am wrong, the XLink recommendation should better have defined
simple links only and explained how extended links can be built from
simple links.

Eric

9/22/06, Nathan Young -X (natyoung - Artizen at Cisco)
<natyoung (AT) cisco (DOT) comwrote:
Hi.

As far as I understand it, topic maps match what you describe below in
significant ways.

Yes, Topic Maps are probably a good match up for some of it. However,
we keep looking at topic maps as more of a higher level tool for
analysis rather than at the inner working level. That may just be due
to a lack of experience with the technology

It would allow for the dynamic merging you describe in the first
paragraph (quoted below), though at this time the implementations lag
far behind those in the relational world in terms of maturity and
standardization.

That sort of confirms my comment above; we really do need a solid and
efficient mechanisms for managing this all. Perhaps it will come in
time?

From your second paragraph (below) topic maps use hierarchical documents
to represent graph structures as you describe. In the topic maps
paradigm you wouldn't usually "reference [an] embedded relationship
graph from the primary document" unless I misunderstand your meaning in
this.

No, we don't really do that explicitly either: the discovery of link
relationships is done by the mapping of the relationship documents to
the primary document by an external process (XSLT in our case)

The third paragraph could be describing topic maps verbatim if you cut
off everything from the first mention of css onward.

And that's the point where the discussion veers away from linking and
into transport and presentation, though that's an important part of
the whole package if you want to have the thing gain traction at all
levels

9/23/06, Ben Trafford <ben (AT) prodigal (DOT) cawrote:
You can talk about semantics and ontologies and all the stuff that
has been spinning the wheels of the *ML communities for the last
twenty years, but until I can render any generic XML with the power
of an XLink, then I'm not interested.

"I don't care about semantics; I only care about meaning!"

are data models (mostly used as systems of logic inference)
that uses linking as _part_ of it. Linking by itself means very
little, in HTML, XML or otherwise. I suspect this debate is once again
about the balance in XML between data and the application of such. As
Key says, what *is* the difference between <element xlink:href=""
/and <element arbitrary-one-way-link="" /in XML in isolation?
Nothing at all. It's *all* about the application of such, even in
XHTML where it means *nothing* until the browser application use the
data for something.

In the worlds of "semantics" and "ontologies" there are defined rules
for what the application mean (you can say that an ontology is a meta
data model; a data model that has implied semantics). It sounds like
you want there to be more generic application specific things in XML,
not less. I'm of the "less" opinion, but only because, well, I'm in
the ontologies camp. :)

You can use <generic_xml_element xhtml:href="" />, though, and play
with that namespace.

Alex

Hiya,

9/23/06, Bob DuCharme <bob (AT) snee (DOT) comwrote:
All right, you asked for it: if a link is a specific relationship between
two identifiable resources relationship that can be implemented with a
hypertext link or with whatever rendering a given medium is capable
of we want to express that link in such a way that the link itself
can have its own metadata, then RDF can do this quite well. It's
particularly good at out-of-line links (and RDF/XML is particularly bad at
inline links).

The key here is where you put the context. To find the context of the
resource in question we need to find that resources place in the
linked-to document, and this is where RDF and Topic Maps are very
different, because we're coming into the realm of merging
domain-views, something Topic Maps were designed to do out of the box
but which XLink nor RDF do well.

I'm only half serious, but I do think that RDF and Topic Maps played a
serious role in XLink's failure

Interestingly, I explored Xlink deeper because I got into Topic Maps

, which was mostly due to the lack of a
community that was excited about XLink enough to implement and promote it.

My biggest problem with Xlink were the reclarifications of something
we all knew from HTML. Why impose a whole standard for linking when
most people would be happy as larry with xml:href or instead just used
xhtml:href? 80/20 :)

(We all know that a spec doesn't have to be good to have such a community
built around it.) People interested in building applications on top of
device-independent methods for expressing information relationships hopped
on the RDF and Topic Map trains, and the XLink train sat in the station
waiting for more passengers than the XBRL folk.

The Topic Maps train has just left the station, while the RDF train
has come back 10 times to pick up more people, even if the service on
the RDF train is reputed to be bad. Crowds think strange, indeed. :)

Alex

>"I don't care about semantics; I only care about meaning!"

9/23/06, Ben Trafford <ben (AT) prodigal (DOT) cawrote:
That's actually not what I was saying, at all.

Sorry; it wasn't meant as a paraphrase at all, just a contextual joke. :)

>that uses linking as _part_ of it. Linking by itself means very
>little, in HTML, XML or otherwise. I suspect this debate is once again
>
Are you using "means" in the ontological sense? As in, the
presence of link doesn't define what that link means?

Then we're in agreement.

Indeed.

>It sounds like
>you want there to be more generic application specific things in XML,
>not less. I'm of the "less" opinion, but only because, well, I'm in
>the ontologies camp. :)
>
I actually don't see how you're finding a conflict between
getting the styling languages to do something smart with links and
the modelling of more generic ontologies.

The word "style" and its "meaning", I suppose. :) To me, style is
presentation and as such only a part of an application of something.
Links is more than presentation, they speak of things "larger" than
that. That's all.

At 07:23 PM 9/22/2006, Alexander Johannesen wrote:
>My biggest problem with Xlink were the reclarifications of something
>we all knew from HTML. Why impose a whole standard for linking when
>most people would be happy as larry with xml:href or instead just used
>xhtml:href? 80/20 :)

That's the common misconception. How many webpages do you go
to where basic link functionality has been extended via scripting
tricks? I'm willing to bet it's quite a few. An example: the Flickr
sidebar at http://www.shelter.nu/.

Not sure I follow you here. What scripting tricks? What is the *trick*?

xhtml:href does -not- win us the 80/20. That's part of my
point. A lot of people are doing a lot of work, having to wrestle
with making it cross-platform, and it could be solved with XLinks in
a standardized and relatively simple way.

<confusedWhich part of "80/20 of linking" doesn't xhtml:href cover?
</confused>

regards,

Alex

Eric van der Vlist wrote:

of the thing which kept popping up is that TM are about defining
links with multiple arcs and this is the domain of extended XLinks.

TM data model is much richer than extended XLinks and it is more high
level and thus provides some direct sementics -- like roles, types and
scopes for each association.

However, XTM has chosen, for the sake of simplicity, to use simple links
rather than extended links.

XTM is just serialization and interchange syntax for Topic maps data
model (TMDM). It could be possible to represent some TM constructs by
extended XLink, but such mapping will be quite artifical and it would
not gain much benefits. of the biggest differences between TM and
RDF is that each association in TM has also its own identity (it is also
topic) so you can make statements about it. IIRIC XLink (similarly to
RDF) doesn't directly support this mechanism.

So, basically XTM is serialization of graph of topic map and simple
XLinks are used to express edges of this graph structure.

If I am right, XTM can hardly pretend to be using XLink :)

XTM uses simple links as defined in XLink specification. ;-)

BTW, recently some people involved in TM development proposed to remove
XLink dependency in a future version of XTM. But I think that final
decision was to stay with current approach.

You can follow discussion here, if you are interested:

Hi,

>Not sure I follow you here. What scripting tricks? What is the *trick*?

9/23/06, Ben Trafford <ben (AT) prodigal (DOT) cawrote:
I mean this code on your site:
How much work went into creating the Javascript to display that sidebar?

Work for me? Little; copy and paste. Work for them? Who knows. But why
do you call this a "trick"? What's tricky about it? Not markup?
Neither is CSS.

Wouldn't it have been much nicer to simply say:
<flickrBar userID="93544306" />
And have CSS do the rest by intelligent placing an embedded, "onLoad" link?

Why? By that you're placing arbitrary code in two places instead of
one. And what about translation rules for the markup of the badge?
CSS1|2 doesn't create markup, so you might be looking to things like
XSLT maybe or CSS3, which, in my personal opinion, is a poor way to
fiddle with content! Is moving the transformation out of the markup
and into the presentation layer a good thing at all, though?

><confusedWhich part of "80/20 of linking" doesn't xhtml:href cover? </confused>
>
Actuation and display of anything beyond single, unidirectional links.

But that's assuming there's more than a 80% need for that, which is
what I'm asking; what is that assumption based on?

Examples:

A menubar link - one click gives you multiple choices.
Sounds like a multi-ended resource to me!

Why? This problem could easily be solved through an embedded (in
browsers) JS object with multiple link support in it. We currently
solve it through custom JS, of course. I know what you're suggesting,
though, but it could be as easy as <a href="http://somewhere
http://somewhere-else http://another-place"></a>

Embedding dynamic content into a document - like your Flickr sidebar.

Not sure I follow you here. You want something generic and dynamic
which isn't a generic and dynamic programming language? Why is your
CSS version better than a JS version?

When we think of rendering links, we need to think beyond
"click and you go there," and we need to think beyond <a>. When
defining where the 80/20 is on links, we need to look at how
resources are being used today -- not how <alinks are being used,
but <img>, <objectand more to the point, the host of scripting
tricks commonly used on the Web.

Well, you don't need to convince me about where we should take links
in general, but in practice I think only automatic parsing benefits
from all the extra work that would go into it, and hence, since the
successful web is built by lazy people, I don't see it happening that
way. If we're to make systems that works best for automata, let's not
hide it in human forms, I'd say. But I fear I just don't understand
what you're trying to say, so there you go :)

regards,

Alex

Hola,

9/24/06, Ben Trafford <ben (AT) prodigal (DOT) cawrote:
When I say "trick," I mean, "a hack for something that
should be based on markup + styling."

"Should be"?

See, you're speaking from the perspective of "Javascript is
the norm, we all use it, it's fine." Ten years ago, the idea that
we'd need scripting on -every- website was abhorrent. Now people accept it.

Not sure I'm writing from any specific perspective as such, but, for
the sake of argument, assuming I do the problem with this is,
what?

As somebody who has written a few thousands lines of
Javascript in my time, let me tell you, CSS support is generally more
coherent across browsers than Javascript support.

Hehe, maybe you just haven't done enough CSS then. :) More seriously,
I disagree with JS support being skewed; it's the various object
models that are different. The object models are *not* the language
JS, but what browsers have chosen to stuff into it. I assume this is
what you're referring to, though, but I still can't accept it; I've
written a few thousand CSS templates in my time, and there is no where
near a coherent support across browsers, even today on simple things
like margins and paddings. JS have had a few more years to sort things
out, and I'm sure CSS will over time as well. But these are both
bolt-on technologies, neither of which are markup so I'm not sure why
you think CSS is somehow "better".

Also, if we keep things in the land of markup vs. the land
of code, we have an easier time with things like accessibility for
websites. CSS is a web accessibility enabler; Javascript is a
disabler, by and large.

Well, depends on the markup, depends on the JS, but in general you're right.

The purist says: code is for doing things -- markup is for
modelling them. So why am I see menus using code for display
purposes? Why aren't they modelled in markup + styling?

Well, that one is easy; there isn't good enough support across all
browsers for doing it in markup + CSS.


>But that's assuming there's more than a 80% need for that, which is
>what I'm asking; what is that assumption based on?
>
Er. The numerous examples I've given in this thread? To
which you've uniformly replied, "Why not just use Javascript?"

Actually, I haven't replied that; you inferred it. But even still, I
don't feel you're adressing the question, which is; what sort of links
do people mostly want to make? How do we know the answer to this? How
do we support it? Are we sure that 80% of what all people want to do
isn't just to throw up an arbitrary link to something?

I think I've answered why, above. People shouldn't need to
learn how to program just to make a good link work.

Uh, ok, but what is the definition of a "good link" as opposed to any
other link?

The need for an 80% is based on the fact that more than 80%
of the sites I go to are using advanced linking features via some
kind of scripting trick, or trying to emulate advanced linking
features with CSS. And these aren't giant corporate portals; these
are personal websites, small businesses, etc.

Some examples? What exactly are you talking about here?

Ten years ago, *ML people simply assumed linking support
would get better over time, so they focused on other things. I don't
think anyone actually expected to be using Javascript for -links- ten
years down the line. It seems natural, and you seem to be taking a
"If it it ain't broke, don't fix it" approach, but I say it only
seems natural because of exposure.

No, I take a rather different approach, which is the simplest use of
the <a /element / tag. I don't like JS anymore than I gather you do.
I'm just unsure about *what* this "better linking" really is, that's
all.

Imagine if someone told you that everytime you wanted to add
visual accessibility options to a page, you needed to code them into
Javascript.

But isn't that all for the features of browsers, and not a feature of
the markup itself?

I mean, heck, the visually impaired are only 10% of the
population. They're not on the right side of the 80/20. And then the
government mandates accessible webpages, so everyone is hacking code
for visual accessibility options into their webpages that work with
dubious functionality depending on the site and browser.

That's because they did a crap job to begin with in terms of
accessibility. Not sure I'm ready to blame poor remedy for *being* a
remedy. :)

Have I made myself clearer?

Not sure. Maybe. I still don't understand your CSS over JS progrom
half the time. Both technologies are there for various reasons, and
some use JS to do what should be in CSS, and some use CSS for what
probably is better in JS, and so forth. Both are technologies that
browsers may or may not do well.

Alex