613 lines
19 KiB
Plaintext
613 lines
19 KiB
Plaintext
head 1.20;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.20
|
|
date 2007.03.05.19.28.54; author RicardoPereira; state Exp;
|
|
branches;
|
|
next 1.19;
|
|
|
|
1.19
|
|
date 2007.02.28.12.44.10; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.18;
|
|
|
|
1.18
|
|
date 2007.02.27.23.45.39; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.17;
|
|
|
|
1.17
|
|
date 2007.02.15.19.47.06; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.16;
|
|
|
|
1.16
|
|
date 2007.02.15.16.09.42; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.15;
|
|
|
|
1.15
|
|
date 2007.02.15.08.20.21; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.14;
|
|
|
|
1.14
|
|
date 2007.02.14.22.10.09; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.13;
|
|
|
|
1.13
|
|
date 2007.02.14.16.19.13; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.12;
|
|
|
|
1.12
|
|
date 2007.02.13.23.18.48; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.11;
|
|
|
|
1.11
|
|
date 2007.02.13.22.13.55; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.10;
|
|
|
|
1.10
|
|
date 2007.02.13.08.33.50; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.9;
|
|
|
|
1.9
|
|
date 2007.02.12.16.23.08; author MarkusDoering; state Exp;
|
|
branches;
|
|
next 1.8;
|
|
|
|
1.8
|
|
date 2007.02.12.15.59.57; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.7;
|
|
|
|
1.7
|
|
date 2007.02.09.02.43.00; author JohnWieczorek; state Exp;
|
|
branches;
|
|
next 1.6;
|
|
|
|
1.6
|
|
date 2007.02.08.10.39.12; author RogerHyam; state Exp;
|
|
branches;
|
|
next 1.5;
|
|
|
|
1.5
|
|
date 2007.02.06.13.38.43; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.4;
|
|
|
|
1.4
|
|
date 2007.02.02.21.11.21; author JavierTorre; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2007.01.31.22.27.54; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2007.01.31.13.54.12; author MarkusDoering; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2007.01.30.22.28.34; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.20
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="RicardoPereira" date="1173122934" format="1.1" version="1.20"}%
|
|
%META:TOPICPARENT{name="WebHome"}%
|
|
---+++ TAPIR Developers Workshop 2007
|
|
|
|
Dates: 12th to 15th of February 2007
|
|
|
|
Venue: GBIF, Copenhagen
|
|
|
|
Times: 9AM to 5PM (lunch from 12:30PM to 1:30PM)
|
|
|
|
The aim of the workshop is to advance the deployment of the TAPIR protocol and augment its community.
|
|
|
|
The workshop will start with a training session and will be followed by hands-on development sessions in separate work groups.
|
|
|
|
---++++ Agenda
|
|
|
|
*Monday*
|
|
|
|
9:00 - 9:10 Welcome<br/>
|
|
9:10 - 10:00 History and overview of TAPIR<br/>
|
|
10:00 - 10:45 Conceptual schemas, output models and query templates<br/>
|
|
Break<br/>
|
|
11:00 - 11:30 Demonstration<br/>
|
|
11:30 - 12:30 Building TAPIR Networks<br/>
|
|
|
|
Lunch
|
|
|
|
13:30 - 15:15 Discussions, individual presentations, planning<br/>
|
|
Break<br/>
|
|
15:30 - 17:00 Work groups & General discussions<br/>
|
|
|
|
-----------------------------------------------
|
|
|
|
*Tuesday* - Work groups & General discussions
|
|
|
|
-----------------------------------------------
|
|
|
|
*Wednesday* - Work groups & General discussions
|
|
|
|
-----------------------------------------------
|
|
|
|
*Thursday* - Work groups & General discussions & Conclusions
|
|
|
|
-----------------------------------------------
|
|
|
|
---++++ Outcomes
|
|
|
|
* Explanation of the main features and concepts of TAPIR to new developers
|
|
* History and overview of TAPIR (Renato).
|
|
* Main concepts about TAPIR: conceptual schemas, output models, query templates, concept name servers (Markus).
|
|
* Demonstration (Javier).
|
|
* Guidelines for building TAPIR networks (Renato).
|
|
* Amendments to the existing TAPIR documentation/specification
|
|
* Search envelopes are turned on by default.
|
|
* Global parameter "xslt" may be subject to restrictions on the allowed hosting domains.
|
|
* Need to include notes about the fact that a provider is not forced to guarantee the entire validity of search responses according to the XML Schema defined in the response structure, except to the extent of its own declared XML Schema capabilities.
|
|
* Include a new attribute "required" at the concept level of output model mapping (defaults to false). Should raise an error when concept is unmapped or the corresponding value is null.
|
|
* Node paths in output model mapping are not considering namespaces. When the response structure needs to make use of different namespaces, they now need to be declared in the outputmodel element and used in the xpaths.
|
|
* XML Schema "include" construct should be added to the possible XML Schema capabilities.
|
|
* When a provider finds an unsupported XML Schema construct it should prefer to raise warnings insrtead of errors.
|
|
* Include new search parameter to instruct providers to omit or not namespaces. Name of the new search parameter: "omitNs".
|
|
* *Should providers handle "elementFormDefault" and "attributeFormDefault" schema attributes, or should we restrict this?*
|
|
* TapirClientDesign: development (at least partially) of new TAPIR client software including libraries and specific data harvesters to be used by biodiversity data networks.
|
|
* Use RSS, DC model, OAI template?
|
|
* TapirHarvester: Library for threaded querying. Extract records automatically from aggregated threads. Manage paging across all providers (remove the ones already full, provide paging interface with fixed page sizes).
|
|
* LsidResolutionWithTapir: discussion, implementation and documentation of LSID resolution service in existing TAPIR provider software.
|
|
* RDF output models in consistency with TDWG ontology.
|
|
* Creation of a generic TapirQueryTool to interact with TAPIR providers.
|
|
* UsingTapirWithExistingConceptualSchemas: discussion and proposals involving DarwinCore, ABCD and other schemas.
|
|
* Creation of new output models and query templates to be used by TAPIR networks.
|
|
* KML output model for DarwinCore providers: http://rs.tdwg.org/tapir/cs/dwc2/model/kml_simple.xml
|
|
* PlinianCore, TCS, NCD.
|
|
* GBIF/ETI REST WS as TAPIR templates.
|
|
* ProviderServiceTests: planning and implementation of interoperability regression tests for TAPIR providers.
|
|
* ComparingTapirAndOai.
|
|
* Other specific developments related to TAPIR
|
|
* GbifTapirIndexer
|
|
* Enhanced ConceptNameServer: specify central service methods, Tonto, multi-language description, definition of what is a conceptual schema (list of concepts only, nothing more), concept synonyms, model+template+xslt repository (how to discover appropiate models).
|
|
* Additional development proposals related to TAPIR.
|
|
|
|
---++++ Demo services
|
|
|
|
http://search.biocase.org/tapir/pywrapper?dsa=training
|
|
|
|
http://test.cria.org.br/tapirlink/tapir.php/test
|
|
|
|
---++++ Comments
|
|
|
|
Main.JavierTorre: I am planning to have fun with Flex (http://www.adobe.com/products/flex/) to create a RIA to test data providers and to be used as a generic TapirQueryTool. Maybe a simple software for ProviderServiceTests could also be implemented.
|
|
|
|
Main.RogerHyam: I am prepared to talk through the TAG.LsidVocs (a.k.a. RDF with TAPIR) that I have been working on. Basically just work through the directory structure and explain how I think/hope this relates to out put models. If you are looking for background on this you could read TAG.LsidVocs, TAG.LsidVocsUsage and TAG.LsidVocsExploring - but this is not required as you may leave me nothing to say. I'd like to spend some time looking at getting these things working.
|
|
|
|
Main.RogerHyam: I have one question that relates to building TAPIR networks. If output models can be remote from wrapper instances then they can be less stable than the concepts that map to them. From the point of view of managing a network it is therefore important to think of stable, agreed concept mapping at each data source but conceptual schema structure is far less important - in fact doesn't have to be agreed on much at all. This radically changes the modeling requirements in a direction I like. Would it be possible for us to put some time exploring this issue and come up with some recommendations or actions?
|
|
|
|
Main.JohnWieczorek: Berkeley has development plans to work on redesigning existing DiGIR portals for TAPIR, including cache management, and to further develop the DiGIR statistics tracking on the provider side to work with TapirLink. The hope is to make a large-scale switch from DiGIR/MaNIS DarwinCore to TAPIR/new DarwinCore plus extensions in the coming year for the 70+providers connected to the vertebrate thematic networks. It's a tall order, so simplicity will be key for the transition.
|
|
|
|
The following notes were taken while each participant talked about general plans related to TAPIR:
|
|
|
|
Main.WouterAddink:
|
|
* Toolkit to share NCD data using TAPIR.
|
|
* Toolkit to share TCS data using TAPIR.
|
|
* Using MySQL & PHP5.
|
|
* Need to define output models, templates.
|
|
* Need also output in json and serialized PHP.
|
|
* Web Services for NLBIF could use TAPIR (all kinds of biodiversity data).
|
|
|
|
Main.JoseCuadra:
|
|
* IABIN Species and Specimen Thematic Network will be based on TAPIR.
|
|
* Using Java, Hibernate, Tomcat, AXIS, PostgreSQL.
|
|
* Using Plinian Core as canonical schema (Javier says that there are already output models for PlinianCore).
|
|
* Requirements:
|
|
* Avoid having to change code when protocol changes.
|
|
* Users need to be able to select output models.
|
|
* Handle structured and unstructured data.
|
|
* More interested in the harvesting part.
|
|
|
|
Main.KevinRichards:
|
|
* Update NZ DiGIR providers to use TAPIR.
|
|
* LSID resolution with TAPIR.
|
|
* Plans to use TAPIR for web services.
|
|
|
|
Main.PatrickLeary:
|
|
* Harvesting name data using TAPIR.
|
|
* Set up a TAPIR service on top of Ubio name database.
|
|
* CustomTapirOperators or maybe CascadingTapirServices to provide taxonomic intelligence.
|
|
|
|
Main.GregWhitbread:
|
|
* AVH is planning to use TAPIR for different types of data (specimen, taxon concept, molecular).
|
|
* Also interested in TapirSpatialOperators.
|
|
|
|
Main.DonaldHobern:
|
|
* GbifTapirIndexer.
|
|
* Plans to use TAPIR for GBIF web services.
|
|
|
|
Main.MilkoSkofic:
|
|
* Interest in deploying TAPIR providers.
|
|
* Need a harvesting solution.
|
|
* Documenting Conceptual Schemas (concept name servers).
|
|
* Repository for output models.
|
|
|
|
Main.JoergHoletschek:
|
|
* Synthesis will need to update client software to work with TAPIR.
|
|
* Plans to upgrade BioCASe providers to TAPIR.
|
|
|
|
Main.YoujunGuo:
|
|
* Integration between Biogeomancer and TAPIR.@
|
|
|
|
|
|
1.19
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1172666650" format="1.1" version="1.19"}%
|
|
d89 1
|
|
a89 1
|
|
JTorre: I am planning to have fun with Flex (http://www.adobe.com/products/flex/) to create a RIA to test data providers and to be used as a generic TapirQueryTool. Maybe a simple software for ProviderServiceTests could also be implemented.
|
|
d99 1
|
|
a99 1
|
|
Main.WoulterAddink:
|
|
@
|
|
|
|
|
|
1.18
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1172619939" format="1.1" version="1.18"}%
|
|
d74 1
|
|
a74 1
|
|
* TapirProviderTestSuite: planning and implementation of interoperability unit tests for TAPIR providers.
|
|
d89 1
|
|
a89 1
|
|
JTorre: I am planning to have fun with Flex (http://www.adobe.com/products/flex/) to create a RIA to test data providers and to be used as a generic TapirQueryTool. Maybe a simple TapirProviderTestSuite could also be implemented.
|
|
@
|
|
|
|
|
|
1.17
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171568826" format="1.1" version="1.17"}%
|
|
d64 2
|
|
d67 1
|
|
a67 1
|
|
* RDF output models in consistency with TDWG ontology
|
|
d72 2
|
|
d78 2
|
|
a79 4
|
|
* ...
|
|
* Additional development proposals related to TAPIR
|
|
* ...
|
|
* ...
|
|
a86 21
|
|
---++++ Topics for break out groups
|
|
|
|
* ConceptNameServer: specify central service methods, Tonto, multi language description, definition of what is a conceptual schema (list of concepts only, nothing more), concept synonyms, model+template+xslt repository (how to discover appropiate models)
|
|
* RDF/LSID
|
|
|
|
* harvester (see query lib)
|
|
* RSS, DC model, OAI template?
|
|
|
|
* models, templates
|
|
* PlinianCore, TCS, NCD
|
|
* GBIF/ETI REST WS as TAPIR templates
|
|
|
|
* client
|
|
* TapirHarvester: Library for threaded querying. extract records automatically from aggregated threads. Manage paging across all providers (remove the ones already full, provide paging interface with fixed page sizes).
|
|
* local querytool. flex/flash
|
|
|
|
* TapirProviderTestSuite
|
|
* for implementation, regression tests with standard DB
|
|
* installation/configuration test -> GBIF?
|
|
|
|
|
|
d97 2
|
|
@
|
|
|
|
|
|
1.16
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171555782" format="1.1" reprev="1.16" version="1.16"}%
|
|
d53 1
|
|
a53 1
|
|
* Amendments to the existing TAPIR documentation
|
|
d56 7
|
|
a62 7
|
|
* Need to include notes about the fact that a provider is not forced to guarantee the entire validity of search responses according to the XML Schema defined in the response structure.
|
|
* Include a new attribute "required" at the concept level of output model mapping (defaults to false). Should raise an error when concept is unmapped or corresponding value is null.
|
|
* Node paths in output model mapping are not considering namespaces. Two options: they should either include a namespace prefix when not coming from the main schema of the response structure (like in xpaths inside xslt stylesheets) or people should not be allowed to import schemas with conflicting element/attribute names
|
|
* XML Schema "include" construct is not part of the XML Schema capabilities.
|
|
* There's nothing in the specification about how should a provider behave when it finds an unsupported XML Schema construct (raise an error or just a warning and continue parsing other things?)
|
|
* Should providers handle "elementFormDefault" and "attributeFormDefault" schema attributes, or should we restrict this?
|
|
* Should we include a new search parameter to instruct providers to omit or not namespaces? Name of the new search parameter: "omitNs"
|
|
d163 1
|
|
a163 1
|
|
* Integration between Biogeomancer and TAPIR.
|
|
@
|
|
|
|
|
|
1.15
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171527621" format="1.1" version="1.15"}%
|
|
d56 7
|
|
a62 6
|
|
* *Need to include notes about the fact that a provider is not forced to guarantee the entire validity of search responses according to the XML Schema defined in the response structure.*
|
|
* *What should a provider do when one of the concepts that are concatenated in an output model mapping is not mapped by the provider?*
|
|
* *Node paths in output model mapping are not considering namespaces. Two options: they should either include a namespace prefix when not coming from the main schema of the response structure (like in xpaths inside xslt stylesheets) or people should not be allowed to import schemas with conflicting element/attribute names*
|
|
* *XML Schema "include" construct is not part of the XML Schema capabilities*
|
|
* *There's nothing in the specification about how should a provider behave when it finds an unsupported XML Schema construct (raise an error or just a warning and continue parsing other things?)*
|
|
* *Should providers handle "elementFormDefault" and "attributeFormDefault" schema attributes, or should we restrict this?*
|
|
d163 1
|
|
a163 1
|
|
* Integration between Biogeomancer and TAPIR.@
|
|
|
|
|
|
1.14
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171491009" format="1.1" reprev="1.14" version="1.14"}%
|
|
d56 1
|
|
a57 1
|
|
* *Need to include notes about the fact that a provider is not forced to guarantee the entire validity of search responses according to the XML Schema defined in the response structure.*
|
|
d162 1
|
|
a162 1
|
|
* Integration between Biogeomancer and TAPIR.
|
|
@
|
|
|
|
|
|
1.13
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171469953" format="1.1" version="1.13"}%
|
|
d58 4
|
|
a61 1
|
|
* *Node paths in output model mapping are not considering namespaces. Two options: they should either include a namespace prefix when not coming from the main schema of the response structure (like xslt does) or people should not be allowed to import schemas with conflicting element/attribute names*
|
|
d68 1
|
|
d97 1
|
|
a97 1
|
|
* library for threaded querying. extract records automatically from aggregated threads. Manage paging across all providers (remove the ones already full, provide paging interface with fixed page sizes).
|
|
d100 1
|
|
a100 1
|
|
* test suite
|
|
d162 1
|
|
a162 1
|
|
* Integration between Biogeomancer and TAPIR.@
|
|
|
|
|
|
1.12
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171408728" format="1.1" version="1.12"}%
|
|
d58 1
|
|
@
|
|
|
|
|
|
1.11
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171404835" format="1.1" version="1.11"}%
|
|
d56 2
|
|
d88 1
|
|
a88 1
|
|
* plinian core, TCS, NCD)
|
|
@
|
|
|
|
|
|
1.10
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171355630" format="1.1" version="1.10"}%
|
|
d54 2
|
|
a55 1
|
|
* None yet.
|
|
@
|
|
|
|
|
|
1.9
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="MarkusDoering" date="1171297388" format="1.1" version="1.9"}%
|
|
d70 6
|
|
d78 1
|
|
a78 1
|
|
* CNS: specify central service methods, Tonto, multi language description, definition of what is a conceptual schema (list of concepts only, nothing more), concept synonyms, model+template+xslt repository (how to discover appropiate models)
|
|
@
|
|
|
|
|
|
1.8
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1171295997" format="1.1" reprev="1.8" version="1.8"}%
|
|
d70 21
|
|
d148 1
|
|
a148 1
|
|
* Integration between Biogeomancer and TAPIR.
|
|
@
|
|
|
|
|
|
1.7
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="JohnWieczorek" date="1170988980" format="1.1" version="1.7"}%
|
|
d49 4
|
|
a52 2
|
|
* ...
|
|
* ...
|
|
d54 1
|
|
a54 2
|
|
* ...
|
|
* ...
|
|
d62 1
|
|
d78 50
|
|
a127 1
|
|
Main.JohnWieczorek: Berkeley has development plans to work on redesigning existing DiGIR portals for TAPIR, including cache management, and to further develop the DiGIR statistics tracking on the provider side to work with TapirLink. The hope is to make a large-scale switch from DiGIR/MaNIS DarwinCore to TAPIR/new DarwinCore plus extensions in the coming year for the 70+providers connected to the vertebrate thematic networks. It's a tall order, so simplicity will be key for the transition.@
|
|
|
|
|
|
1.6
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RogerHyam" date="1170931152" format="1.1" reprev="1.6" version="1.6"}%
|
|
d75 2
|
|
@
|
|
|
|
|
|
1.5
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1170769123" format="1.1" version="1.5"}%
|
|
d70 5
|
|
a74 1
|
|
JTorre: I am planning to have fun with Flex (http://www.adobe.com/products/flex/) to create a RIA to test data providers and to be used as a generic TapirQueryTool. Maybe a simple TapirProviderTestSuite could also be implemented.@
|
|
|
|
|
|
1.4
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="JavierTorre" date="1170450681" format="1.1" reprev="1.4" version="1.4"}%
|
|
d15 32
|
|
a46 1
|
|
Outcomes of the workshop:
|
|
d57 1
|
|
a57 2
|
|
* Creation of a generic query tool to interact with TAPIR providers.
|
|
* JTorre: I am planning to have fun with Flex (http://www.adobe.com/products/flex/) to create a RIA to test data providers and to be used as a generic QueryTool. Maybe a simple TapirProviderTestSuite could also be implemented.
|
|
d67 4
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1170282474" format="1.1" version="1.3"}%
|
|
d27 1
|
|
d36 1
|
|
a36 1
|
|
* ...@
|
|
|
|
|
|
1.2
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="MarkusDoering" date="1170251652" format="1.1" reprev="1.2" version="1.2"}%
|
|
d3 1
|
|
a3 1
|
|
---+++ TAPIR Developers Workshop
|
|
d9 2
|
|
d30 3
|
|
d35 1
|
|
a35 1
|
|
* ...
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RenatoDeGiovanni" date="1170196114" format="1.1" reprev="1.1" version="1.1"}%
|
|
d23 1
|
|
@
|