[
Lists Home |
Date Index |
Thread Index
]
Dave Pawson <davep@dpawson.co.uk> writes:
>
> On Mon, 2004-10-25 at 01:50, Michael Champion wrote:
> > On Sun, 24 Oct 2004 14:44:23 -0700, Ronald Bourret
> > <rpbourret@rpbourret.com> wrote:
> >
> > > For example, given the element <part>123</part>, it would
> be nice to
> > > link this with a document containing more information about part
> > > 123, but XQuery would need to know where to go looking for that
> > > document.
> > >
> > > One possibility is some sort of external document containing link
> > > information,
> >
> > That's what an ontology does, I think. Not link information, but
> > relationship information, which could be used by an application to
> > follow links, or generate XQuery, DOM, XSLT, or whatever to
> leverage
> > the relationship information.
>
> That sounds a lot better than links to me; relationship
> information. Some apps may want to generate hyperlinks from
> the combination of relationships and document(s), others may
> do other things as Peter suggests.
>
> So there are now three things.
> doc.xml
> relationships.xml
> and
> application.exe which plays with combinations of the above
> using some collection of todays tools.
Seems reasonable, but somehow I can't stop from feeling building
application.exe "using some collection of todays tools" is akin to
saying "here magic happens"? See below...
> >
> > > On a related point, I think it would be nice to be able
> to just say,
> > > "This is a link," without any of the additional explanatory
> > > information that XLink gives (type, role, etc.).
> I'd put these into application.exe? I want to show this
> relationship in this specific way for that specific purpose?
> Sort of configuration information for application.exe?
>
>
> > The advantage of this is
> > > simplicity, and it really isn't that unreasonable when you think
> > > about
> > > it: Most interpretation of XML documents is application
> specific anyway,
> > > so why should links be any different?
>
> I like that.
>
> >
> > Agree! So should that be a core part of some future XML,
> or a small
> > supplemental spec on the order XML Base, or what?
>
> I'll leave that to others :-)
> But I do like it 'outside' my xml instance.
> Keeps the xml instance nice and simple? I've only got points
> (id's?) and Gavin tells me they could equally well be put in
> the relationships.xml document[1]. KISS principle?
> Would that mix nicely with XML-- which steps gracefully
> from docHead world to dataHead world? No id/idref pairs?
>
Ok, even if "todays tools" do what Gavin suggests, you've got a
bootstrap problem: how do you know what combinations of documents to use
together? Some fourth linking document? Some instance information
inside one of the documents? in the form of a link? An addressable
ontology somewhere (pointed to by what)?
> >
> > So, the "this is a link" namespace or whatever for simple
> things, and
> > OWL for the times when you really do need to specify the direction,
> > type, role, etc. of a relationship, maybe?
>
> Or something quite simple and in between until the need for
> the OWL's wisdom is perceived?
I'm not sure it's until "OWL's wisdom is perceived", but rather "until
OWL's processing overhead can be afforded for general use", but either
way, a stop gap would be nice...
|
