PROCEEDINGS OF FOURTH BERKELEY CONFERENCE ON DISTRIBUTED DATA MANAGEMENT AND COMPUTER NETWORKS.
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
Data base access is increasingly important in a networking environment.Two alternative approaches can be identified: i) implementation of distributed databases presenting the user with one logical database implemented across a collection of computers or, alternatively, ii) development of network data managers providing a uniform user and program viewpoint across heterogenous DBMSs.While the first approach is the most natural extension of the concept of an individual DBMS, its utilization imposes certain requirements including the necessity for converting existing DBMSs if their data is to be supported in the distributed environment.The second approach minimiz.esor eliminates cO"lwersion problems; however, it has not yet caen shown feasible.This paper describes an ongoing research project concerned with establishing the feasibility, issues, alternatives, and a technical approach for supporting a network data manager.Although implementation has not been completed, the initial evidence is positive and suggests that network data managers may well prove either an acceptable alternative or useful intermediate stage to a distributed database.Perhaps the three key issues in ensuring user acceptance of a network data manager are: i) access controls and semantic integrity, ii) developing more sophisticated translation capabilities optimizing the allocation of the translation process among NOM and LDBMS, and iii) performance.We believe the basic issues and a reasonable approach for (i) have, been discussed in this paper.Developing a more sophisticated translation capability is of obvious importance and closely relates to the performance issue.Implementation of translators should be paralleled with research directed toward a better understanding of the nature of the translation process.Some work is beginning to appear in this area [KLUGA 78] establishing the theoretical limits of translation feasibility. Implementation StatusXNDM translation is performed on a PDp11 /45 attached to the Arpanet as are the other host computers.Tbe operating system for the PDp11 145 is UNIX [THOMK 74] and the translator' is programmed in C. To provide a more uniform interface to the translator, small support modules termed envelopes are implemented on the system on which each LDBMS resides.Basic communications support between systems and the ability to preserve meaning ,in transporting structured records between heterogeneous systems is provided by. an Experimental Network Operating System (XNOS) [KIMBS 78].Work on the XNQL translator is still in progress.The current version handles two out of the six XNQL constructs (selections of columns and rows), for the following target systems:the Multics Relational Data Store (MRDS) [HONEY 77], a relational calculus system, and the Honeywell 600/6000 Integrated Data Store (IDS) [HONEY 71], a Codasyllike system.For MRDS, the translator can handle all target data structures In general, but for IDS, target records with multiple owners and multiple members are excluded. Implementation ApproachTwo different approaches to implementing XNDM can be considered.The first distributes the implementation across the supported host systems whiie the second, which we have adopted, offloads the implementation, to the extent possible, onto a separate satellite computer.The tradeoffs between these two approaches are essentially those of evaluating the cost of supporting an additional computer versus the cost of implementing common modules on several different systems.Given the opportunity for centralized design, implementation and support.afforded by offloading and the increasingly high' cost of software, we believe that offloading is the natural approach in an evolving technology.The alternative might be appropriate for an extremely static environment.6.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,000 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,001 | 0,007 |
| Science ouverte | 0,002 | 0,003 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle