Kurt,
I know little about how relational databases are put together
but the us-gaap taxonomy was built in and stored in a relational database.
I’ll say that when the current taxonomy project started in 2007, the
applications were pretty shaky but with constant user feedback we got it stable
and where we needed it. We had as many as 50 people hitting the database with
changes at any point in time. We could never have gotten it done without
the multiuser capability, which presumably requires a database structure.
I imagine that most of the large XBRL taxonomies are maintained in
databases. The problem must have been resolved.
Louis Matherne
From: Kurt Cagle
[mailto:kurt.cagle@gmail.com]
Sent: Thursday, August 27, 2009 2:28 PM
To: Michael Kay
Cc: Louis Matherne; xml-dev@lists.xml.org
Subject: Re: [xml-dev] XPointer is dead. What about XLink?
I think the interesting question to ask is whether XBRL
gains any benefits
as a result of the decision to use the XLink vocabulary for linking, rather
than inventing its own? For example, does the reuse of vocabulary elements
enable any reuse of an underlying software layer? Or does it enable the
reuse of skills and knowledge associated with that vocabulary? Because
unless it achieves such benefits, it would surely have been better to design
a vocabulary more finely tuned to the specific needs of XBRL.
This is very much the same argument that I've used with people like David Vun
Kannon. XLinks and link bases were seen as a way of solving a perceived problem
- differences in semantic representation as well as localization and
computational efforts, rather than dealing with these issues primarily as
schematic issues or SemWeb (in defence of the position, I'd also argue that
SemWeb has matured considerably since XBRL first emerged as well). The downside
with XBRL is link resolution - link arcs force a two or three level deep
dereferencing problem that can be hellish on most XML implementations, and that
apparently give relational databases heartburn as well.
Unfortunately, there comes a point where legacy implementations carry their own
weight, regardless of the merit of the technology. If I was an ontologist
working with the nascent XBRL.org group in 2000 with the tools we have today, I
would have recommended a different architecture, but this is probably true of a
late of BIG ontologies.
Having said that, I think the other issue involved is the degree to which xlink
overlaps with SemWeb, which I see as the natural extrapolation of such linkage
systems. As Michael Kay indicated, xlink as it exists right now is very much
tied into the notion of client implementations, and its a valid question as to
whether the specific characteristics of such links should in fact be very much
client language specific (which also raises the intriguing notion of whether
link characteristic specification may not in fact also have schematic
implementation beyond the base-bones notion of ID and IDREF). Given the recent
work to push HTML 5 forward, it may be a good time to revisit xlink and its
more feature-rich sister xinclude.
As to XPointer - yeah, it's dead, Jim. XPointer was a very early attempt to
introduce some type of basic document query capability into an XML document,
and as such it placed too many expectations on the server responding in a
systematic way to such a query. What seems to be emerging in its place are
RESTful services based upon existing data stores (XRX being the primary
proponent there in the XML space) with utilize a query mechanism (XQuery or
SPARQL, in this case) in order to retrieve appropriate fragments. I don't think
many people mourn its passing.
|
