Search (5 results, page 1 of 1)

0.022689465 = product of:
  0.04537893 = sum of:
    0.04537893 = product of:
      0.09075786 = sum of:
        0.09075786 = weight(_text_:l in 3440) [ClassicSimilarity], result of:
          0.09075786 = score(doc=3440,freq=2.0), product of:
            0.20667124 = queryWeight, product of:
              3.9746525 = idf(docFreq=2257, maxDocs=44218)
              0.05199731 = queryNorm
            0.4391412 = fieldWeight in 3440, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.9746525 = idf(docFreq=2257, maxDocs=44218)
              0.078125 = fieldNorm(doc=3440)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.021134753 = product of:
  0.042269506 = sum of:
    0.042269506 = product of:
      0.08453901 = sum of:
        0.08453901 = weight(_text_:22 in 3895) [ClassicSimilarity], result of:
          0.08453901 = score(doc=3895,freq=2.0), product of:
            0.18208572 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.05199731 = queryNorm
            0.46428138 = fieldWeight in 3895, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.09375 = fieldNorm(doc=3895)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

24. 8.2005 19:20:22

0.017612295 = product of:
  0.03522459 = sum of:
    0.03522459 = product of:
      0.07044918 = sum of:
        0.07044918 = weight(_text_:22 in 539) [ClassicSimilarity], result of:
          0.07044918 = score(doc=539,freq=2.0), product of:
            0.18208572 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.05199731 = queryNorm
            0.38690117 = fieldWeight in 539, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.078125 = fieldNorm(doc=539)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

26.12.2011 13:22:07

0.012835099 = product of:
  0.025670199 = sum of:
    0.025670199 = product of:
      0.051340397 = sum of:
        0.051340397 = weight(_text_:l in 1206) [ClassicSimilarity], result of:
          0.051340397 = score(doc=1206,freq=4.0), product of:
            0.20667124 = queryWeight, product of:
              3.9746525 = idf(docFreq=2257, maxDocs=44218)
              0.05199731 = queryNorm
            0.24841578 = fieldWeight in 1206, product of:
              2.0 = tf(freq=4.0), with freq of:
                4.0 = termFreq=4.0
              3.9746525 = idf(docFreq=2257, maxDocs=44218)
              0.03125 = fieldNorm(doc=1206)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

The Alexandria Digital Library Project announces the online publication of two protocols to support querying and response interactions using distributed services: one for gazetteers and one for thesauri. These protocols have been developed for our own purposes and also to support the general interoperability of gazetteers and thesauri on the web. See <http://www.alexandria.ucsb.edu/~gjanee/gazetteer/> and <http://www.alexandria.ucsb.edu/~gjanee/thesaurus/>. For the gazetteer protocol, we have provided a page of test forms that can be used to experiment with the operational functions of the protocol in accessing two gazetteers: the ADL Gazetteer and the ESRI Gazetteer (ESRI has participated in the development of the gazetteer protocol). We are in the process of developing a thesaurus server and a simple client to demonstrate the use of the thesaurus protocol. We are soliciting comments on both protocols. Please remember that we are seeking protocols that are essentially "simple" and easy to implement and that support basic operations - they should not duplicate all of the functions of specialized gazetteer and thesaurus interfaces. We continue to discuss ways of handling various issues and to further develop the protocols. For the thesaurus protocol, outstanding issues include the treatment of multilingual thesauri and the degree to which the language attribute should be supported; whether the Scope Note element should be changed to a repeatable Note element; the best way to handle the hierarchical report for multi-hierarchies where portions of the hierarchy are repeated; and whether support for searching by term identifiers is redundant and unnecessary given that the terms themselves are unique within a thesaurus. For the gazetteer protocol, we continue to work on validation of query and report XML documents and on implementing the part of the protocol designed to support the submission of new entries to a gazetteer. We would like to encourage open discussion of these protocols through the NKOS discussion list (see the NKOS webpage at <http://nkos.slis.kent.edu/>) and the CGGR-L discussion list that focuses on gazetteer development (see ADL Gazetteer Development page at <http://www.alexandria.ucsb.edu/gazetteer>).

0.009047496 = product of:
  0.018094992 = sum of:
    0.018094992 = product of:
      0.07237997 = sum of:
        0.07237997 = weight(_text_:authors in 2362) [ClassicSimilarity], result of:
          0.07237997 = score(doc=2362,freq=6.0), product of:
            0.23704608 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.05199731 = queryNorm
            0.30534133 = fieldWeight in 2362, product of:
              2.4494898 = tf(freq=6.0), with freq of:
                6.0 = termFreq=6.0
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.02734375 = fieldNorm(doc=2362)
      0.25 = coord(1/4)
  0.5 = coord(1/2)

Abstract

The paper analysed here is a kind of position paper. In order to get a better under-standing of the reported work I used the retrieval interface of the thesaurus, the so-called NCI DTS Browser accessible via the Web3, and I perused the cited OWL file4 with numerous "Find" and "Find next" string searches. In addition the file was im-ported into Protégé 2000, Release 2.0, with OWL Plugin 1.0 and Racer Plugin 1.7.14. At the end of the paper's introduction the authors say: "In the following sections, this paper will describe the terminology development process at NCI, and the issues associated with converting a description logic based nomenclature to a semantically rich OWL ontology." While I will not deal with the first part, i.e. the terminology development process at NCI, I do not see the thesaurus as a description logic based nomenclature, or its cur-rent state and conversion already result in a "rich" OWL ontology. What does "rich" mean here? According to my view there is a great quantity of concepts and links but a very poor description logic structure which enables inferences. And what does the fol-lowing really mean, which is said a few lines previously: "Although editors have defined a number of named ontologic relations to support the description-logic based structure of the Thesaurus, additional relation-ships are considered for inclusion as required to support dependent applications."
According to my findings several relations available in the thesaurus query interface as "roles", are not used, i.e. there are not yet any assertions with them. And those which are used do not contribute to complete concept definitions of concepts which represent thesaurus main entries. In other words: The authors claim to already have a "description logic based nomenclature", where there is not yet one which deserves that title by being much more than a thesaurus with strict subsumption and additional inheritable semantic links. In the last section of the paper the authors say: "The most time consuming process in this conversion was making a careful analysis of the Thesaurus to understand the best way to translate it into OWL." "For other conversions, these same types of distinctions and decisions must be made. The expressive power of a proprietary encoding can vary widely from that in OWL or RDF. Understanding the original semantics and engineering a solution that most closely duplicates it is critical for creating a useful and accu-rate ontology." My question is: What decisions were made and are they exemplary, can they be rec-ommended as "the best way"? I raise strong doubts with respect to that, and I miss more profound discussions of the issues at stake. The following notes are dedicated to a critical description and assessment of the results of that conversion activity. They are written in a tutorial style more or less addressing students, but myself being a learner especially in the field of medical knowledge representation I do not speak "ex cathedra".