|
|
Main.LinkingGraphsInCytoscapeAndOntologies History
Hide minor edits - Show changes to markup
February 07, 2008, at 11:16 AM
by 129.20.167.23 -
Added lines 6-7:
Note: mapping is specified for nodes only!
February 07, 2008, at 11:06 AM
by 129.20.167.23 -
Changed lines 19-22 from:
1 Each rules appers with its own panel. The Results panel presents all mappings URI to ID "resolved"
2 Creates a new mapping rule
to:
1 Each pattern appers with its own panel. The Results panel presents all mappings URI to ID "resolved"
2 Creates a new mapping pattern
Changed lines 29-32 from:
6 Add the rule to memory (not persistent. For this use save in the analysis context menu).
7 Resolve URI to IDs association following this rule. The results are visible in the Results panel (1). Note that resolve takes into account all the mapping rules specified, and not only the one displaied.
to:
6 Add the pattern to memory (not persistent. For this use save in the analysis context menu).
7 Resolve URI to IDs association following this pattern. The results are visible in the Results panel (1). Note that resolve takes into account all the mapping patterns specified, and not only the one displaied.
Changed lines 39-40 from:
9 Delete the rule currently displaied.
to:
9 Delete the pattern currently displaied.
February 07, 2008, at 10:41 AM
by 129.20.167.23 -
Changed lines 56-58 from:
6 The amount of availabel microarray data thatcan be associated to URIs.
to:
6 The percentage of available microarray data thatcan be associated to URIs.
February 07, 2008, at 08:55 AM
by 129.20.167.23 -
Changed lines 6-7 from:
Mapping ontologies to generic Cytoscape networks is the first step of a set of features that will enable tighter integration between experimental data and ontologies. As these features are not yet implemented in the current release (0.4), some of the functionalities presented in this section could be unstable. Please report any bug or comment.
to:
Mapping ontologies to generic Cytoscape networks is the first step of a set of features that will enable tighter integration between experimental data and ontologies. As these features are not yet implemented in the current release (0.4), some of the functionalities presented in this section could be unstable. Please report any bug or comment.
February 07, 2008, at 08:54 AM
by 129.20.167.23 -
Added line 18:
Added line 20:
Added line 22:
Added line 24:
Added line 26:
Added line 28:
Added line 30:
Added line 32:
Added line 38:
Changed lines 42-43 from:
Mapping of data is controlled through this panel. Note that at this point (v. 0.4) maping of microarray data can be executed, but does not enable other functionalities than those already present in RDFScape/Cytoscape.
to:
Mapping of data is controlled through this panel. Note that at this point (v. 0.4) maping of microarray data can be executed, but does not enable other functionalities than those already present in RDFScape/Cytoscape. Once mapping is performed, mapped node in teh Cytoscape graph will be available for browsing or querying.
Changed lines 45-52 from:
to:
1 Issue mapping of ontologies to the current network. Note that this mapping uses the output of the Resolve operation that is not executed automatically !!!
2 The percentage of the URIs for which a mapping was specified that found a node in the current network.
3 The percentage of nodes in this network to which an URI was associated.
4 Once a mapping is performed, linking ontologies to microarray data is enabled.
5 The percentage of URIs for which a mapping was specified that can be associated to microarray data (note: this does not take into account mapping to the Cytoscape network!!! these two values can potentially be independent).
6 The amount of availabel microarray data thatcan be associated to URIs.
February 07, 2008, at 08:49 AM
by 129.20.167.23 -
Changed lines 12-13 from:
Mappings are specified through a set of pattern, whose body is included in a set of queries evaluated in OR. See below for details:
to:
Mappings are specified through a set of pattern, whose body is included in a set of queries evaluated in OR. The logic is the following:
patterns are composed in a query, among the results of this query it is possible to specify which element in the pattern was an URI to be mapped, and which is a Literal corresponding to an identifier to be found in the network. This specification can be stored in an analysis context and it's not intended for the final user. It is possible thorugh it to map set of ontologies containing (or importing) specific information to realize this mapping. One example is the use of the Xref mechanism in biopax.
See below for details:
Changed lines 18-19 from:
to:
1 Each rules appers with its own panel. The Results panel presents all mappings URI to ID "resolved"
2 Creates a new mapping rule
3 Here the text of the rule must be specified as a pattern (the same syntax as for RDQL queries applies, but only the WHERE clause must be entered here. In the image a correct pattern is shown).
4 Which variable in the pattern is the URI
5 Which variable in the pattern is the ID
6 Add the rule to memory (not persistent. For this use save in the analysis context menu).
7 Resolve URI to IDs association following this rule. The results are visible in the Results panel (1). Note that resolve takes into account all the mapping rules specified, and not only the one displaied.
8 Synthesis of the resolve operation results:
- URIs: The total number of URIs identified by the specified patterns
- IDs: The total number of IDs identified by the specified patterns
- Conflicts: The number of cases in which two URIs can be attributes to the same ID. Note that this situation should not conceptually happen (each node is assumed to represent one concept in the ontology). The ontology should be augmented accordingly (through a proper mapping file). No garantee are done on the result: only one of the possible URIs chosed randomly will be assigne to the node.
- Multi:. The number of URIs that have multiple Identifier. This is possible, but should not be the standard consition in which analysis of microarray data will be applied.
9 Delete the rule currently displaied.
Changed lines 35-44 from:
http://www.sgtp.net/AndreaSplendiani/ext/rdfscape/screenShotRDFScapeCytomapper2.png
to:
http://www.sgtp.net/AndreaSplendiani/ext/rdfscape/screenShotRDFScapeCytomapper2.png
1
2
3
4
5
6
FAQ
February 07, 2008, at 08:32 AM
by 129.20.167.23 -
Added lines 1-20:
Linking networks in Cytoscape to ontologies
RDFScape allows to map ontologies to generic networks present in Cytoscape. This functionality is implemented in two steps:
The instructions to perform this mapping can be specified in the Mapiing ontologies on Cytoscape networksI panel under configure options. The actual execution of the mapping is controlled through the panel Map ontologies to my network.
Mapping ontologies to generic Cytoscape networks is the first step of a set of features that will enable tighter integration between experimental data and ontologies. As these features are not yet implemented in the current release (0.4), some of the functionalities presented in this section could be unstable. Please report any bug or comment.
Instructions
Mapping specifications
Mappings are specified through a set of pattern, whose body is included in a set of queries evaluated in OR. See below for details:
http://www.sgtp.net/AndreaSplendiani/ext/rdfscape/screenShotRDFScapeCytomapper1.png
Mapping control
Mapping of data is controlled through this panel. Note that at this point (v. 0.4) maping of microarray data can be executed, but does not enable other functionalities than those already present in RDFScape/Cytoscape.
http://www.sgtp.net/AndreaSplendiani/ext/rdfscape/screenShotRDFScapeCytomapper2.png
|
|