80 lines
6.6 KiB
Plaintext
80 lines
6.6 KiB
Plaintext
head 1.3;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.3
|
|
date 2006.02.20.21.50.35; author RicardoPereira; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2006.02.13.12.03.40; author RicardoPereira; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2006.02.13.10.09.46; author DonaldHobern; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@
|
|
.
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@
|
|
.
|
|
@
|
|
text
|
|
@---++ GUID-1 Workshop Report Comments
|
|
|
|
Please use this page to provide any comments on the [[GUID1Report][report from the first GUID Workshop]].
|
|
|
|
----
|
|
[[Bob][Morris' original post on http://wiki.cs.umb.edu/twiki/bin/view/SDD/RDFConsideredHarmful SDD Wiki]]:
|
|
|
|
I'm quite confused from the meeting reports whether there was some argument accepted that LSID metadata in RDF should represent the \content/ of the current concerns of TDWG, including TCS, DC, ABCD, SDD, and the impending new groups, or merely \describe/ the databases against which answers are rendered in those content standards. For example, if a taxon concept is given an LSID, is the metadata returned expected to be a replacement for the current XML constrained by TCS? RDF certainly can encode a taxon concept and address the relations it encodes, but I'm unaware of applications of LSID metadata of objects in a database where the datum is encoded, though in many cases RDF could rationally make a claim to do so. I agree with Sally:Where's the robust, widely accepted killer app?
|
|
|
|
See my take on Rod's take on McCool's take on the failure of RDF. Basically I agree with Rod in theory but not in reality. You can see it in my response in his blog. I cited McCool because he is the most qualified I have every seen of the many who write that RDF is still a technology in waiting. One blogger claims that an MIT RDF adherent couldn't give a single instance of content in RDF other than constructed examples. http://www.zacker.org/the-battle-for-the-semantic-web-rdf-vs-xml. In 1998, that paragon of scholarship Byte magazine, predicted that RDF would be the most important application of XML. http://www.byte.com/art/9803/sec5/art4.htm A host of more explicit predictions for RDF in that article remain (realistic) promises.
|
|
|
|
The problem with RDF is that enterprise-class applications still seem to be a somewhat realistic promise, but a promise nevertheless. XML Schema, for all its warts and expressive power weaker than RDF and RDFS, is the foundation of quite a bit of robust application software. There's even a public XML Schema from Microsoft that constrains what happens when you select "Save as XML" in Excel, (to which, I am given to understand, Open Office also conforms). Lately I've learned that if a technology supports spreadsheets, biologists will say "lead me to it", or at least will not run away from it.
|
|
|
|
If the proposal is just to encode LSID metadata about databases for which exchange documents are being generated, my feeling is that this is somewhere between harmless and useful, mainly for discovery and baby machine reasoning during discovery. If the proposal is to re-encode ABCD, TCS, DC and SDD in RDF, it is somewhere between harmless and harmless, but VERY time consuming for a community of volunteers for not much near-term gain. In the former case, I see little need to have distinct efforts for each subgroup. I suspect that this is principally a re-expression in RDF of some, or even most, of the concerns of UBIF, and that it is independent of any subgroup. If one accepts that the exchange standards remain in XML-Schema, with all its warts, weaker expressive power and weaker extensibility than RDF, then a maintenance problem arises: there are two sets of infrastructures and tools to be supported: those for XML and those for RDF. It may be that, in this scenario, the discovery applications of RDF are sufficiently isolated from the content issues that most people won't be impacted by LSID metadata represented in RDF, except to whatever extent they find what they are looking for more easily. So it may not be a big deal. Or it may be.
|
|
|
|
For some concerns, notably those of TCS, there is already a very mature ontology language (which, however, has a somewhat shaky representation in RDF as well as its more mature representations). This is UMLS, the Unified Medical Language System a 25 year old effort whose killer apps are used regularly and invisibly by everybody who visits the U.S. National Library of Medicine. One effort by Neil Sarkar at AMNH has found that about 60% of the Torrey Bueno Glossary of Entomolgy is already encoded in UMLS where the ontological concerns of entomologists intersect those of medical researchers. Neil has organized a session next week at the AAAS meeting in St. Louis. Bryan Heidorn will give a talk about SDD.
|
|
|
|
People at the Sydney 2001/2001bis TDWG/GBIF meetings may see some irony here if they recall that I argued then for RDF as the representation language for SDD and was beaten down on the grounds that it was too complex and too untried. I found this a strange argument because we turned to another complex and untried technology, XML Schema, but made it work. However, what alarms me is that XML Schema caught on, and RDF remains controversial for its original goals. So now I'm on the other side, at least for a few more years. That said, it's always been my lab's intention to use RDF \externally/ to SDD to compare controlled vocabularies (Terminologies, in SDD). As I reported in St. Petersburg, we use XML databinding frameworks to generate SDD import/export programs and I expect that these actually will automate the process of generating RDF too. I don't know what are the corresponding tools for generating RDF marshalling and unmarshalling code. If there aren't any, then I am really convinced that RDF hasn't yet arrived. [Marshalling is the process of translating the serialization language, say RDF, into objects in your programming language; unmarshalling the reverse. It is desirable for many reasons to have such code not written by hand, but rather to be generated with only defined in the serialization constraint language (RDFS?) as input ].
|
|
|
|
Finally—although there is nothing inherently wrong with this—all new users of a new representation language for solving any information delivery problems typically make naïve use of the language. This happened in TDWG with XML Schema and it will happen in TDWG in RDF. Whatever you think your required time to provide good RDF generation, add 100% for rewriting it in \good/ RDF after you finally understand RDF from your first system.
|
|
|
|
-- BobMorris - 13 Feb 2006 @
|
|
|
|
|
|
1.2
|
|
log
|
|
@
|
|
.
|
|
@
|
|
text
|
|
@d6 1
|
|
a6 1
|
|
Bob Morris' original post on SDD Wiki:
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@Initial revision
|
|
@
|
|
text
|
|
@d3 20
|
|
a22 1
|
|
Please use this page to provide any comments on the [[GUID1Report][report from the first GUID Workshop]].@
|