Alan, Ed, Kingsley, Michael, and Juan, (01)
I didn't use the word 'marginal', but it's fair to say that the SW has
not become part of mainstream IT. I also believe that the adoption
rate of the SW could have been much, much faster if the DAML project
had implemented what Tim B-L proposed. (02)
AR
> I vigorously disagree with the characterization of the SW as marginal (03)
The DAML proposal (Feb 2000) emphasized three key goals, which are
essential for integrating the SW with mainstream IT. But none of
those terms are mentioned in the DAML final report of 2005: (04)
Diversity, heterogeneity, and interoperability. (05)
If the technology outlined in Tim's original proposal had been
implemented -- perhaps not in 2005, but maybe 2010 -- I would be
as vigorous a supporter of the SW as you are. (06)
EJB
> I agree strongly with John Sowa (for a change). “Extended RDBMS” are
> what the world runs on, and they have survived two fad replacement
> technologies. RDF will simply be the third. As John says, RDF can be
> a data representation at the interface to a data repository, but it
> provides no fundamentally different value. SPARQL is just another query
> language, and a good “extended RDBMS” can run SPARQL queries... (07)
I'm glad that we agree on the central issues and their implications. (08)
JFS
>> Fundamental requirement: Equal support for SQL and SPARQL. (09)
KI
> Yes! (010)
I knew that you would agree to that, since you and your colleagues have
been designing and implementing tools to support them. (011)
KI
> R2RML is really about portable declarative views for bridging SQL RDBMS
> hosted data with RDF based Linked Data. Sadly, this isn't the narrative
> that sticks out at first blush (012)
The narrative of interoperability does not stick out because the SW
boosters have been preaching the hype that converting from RDB to RDF
will bring some miraculous benefits. (013)
Unfortunately, there are horror stories from businesses that got
badly burned by converting their business data from RDB to RDF
(for reasons along the lines that Michael mentions). (014)
KI
> DBMS products weren't historically built to co-exist. They were built
> to compete against each other on the basis of core DBMS features
> (for which interop is an afterthought). (015)
Customers always want interoperability. Small companies want to make
their tools interoperable with products from the dominant companies.
But the dominant companies add incompatible "goodies" in order to
lock users into their fiefdoms. (016)
That is why I recommended Datalog as a clean common core that can be
mapped to and from relational or graph DBs. Tim B-L's proposal can
support Datalog as a subset of SWeLL (Semantic Web Logic Language).
But the tools developed by the DAML project cannot. (017)
MB
> What about SPARQL transactions ? Starting a transaction, reading and
> updating, committing the transaction. Is there a triple store that
> supports this with all the fidelity of modern RDB systems ?
>
> There should be a big warning sign above the SPARQL UPDATE standard
> for those who think relational databases are legacy. (018)
Yes indeed. Maintaining data integrity has been and always will be
an absolute requirement for a commercial DBMS. (019)
KI
> Change sensitivity is handled via the use of Linked Data Views
> over disparate data sources...
>
> We have Replication (Snapshot and Transactional) and HTTP (including
> cache invalidation) baked into Virtuoso. (020)
I agree that if you have complete control over all the data, you can
implement some sort of transaction-based control mechanism. (021)
But if the RDF comes from arbitrary pages on the WWW, there is no way
you can load them all into a local store (cache or whatever), make the
updates, store the changes back to the WWW, and guarantee that nobody
modified anything between the download and the upload. (022)
Juan S.
> In my (short) experience, talking to real businesses and customers,
> many people consider RDBMSs as legacy systems.
>
> All in all, people want to bridge a previous technology (RDBMS)
> with new technology (Semweb). (023)
Graph databases are *older* than relational databases. And bridging
by means of batch translation does *not* support interoperability. (024)
For the term 'legacy', I'll quote Ed's comment in his previous note: (025)
EJB
> What makes a system a “legacy” is not the technology used, unless
> that technology is no longer supported, but rather its relevance
> to the way you currently do business. (026)
I agree. (027)
John (028)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (029)
|