Science Collaboration Framework

After dreaming about using views to query other databases, namely pubmed... and having an import button for the content you really want... I realized that rather than writing views understanding of authors and mesh terms and titles to be able to add to the URL query entrez wonderfully allows us to query PubMed and other databases with.... it would be far, far easier to give the people who need to find articles an 'import this article' button in the browser.

The nodes are, in fact, being saved. They are in the Drupal database node table with a user ID of zero.

Very very oddly, however, instead of displaying $node->uid = 0 nodes as authored by "Anonymous" (or "Visitor" or whatever you changed your anonymous user string to), Drupal returns "Page not found."

Weirdness.

Anyhow, the cause in this case is the way information is getting passed to biblio_node_save.

[Note-- "ODL" below should be read as OWL-DL or OWL DL, see http://www.w3.org/TR/owl-guide/ ]
See wikipedia FRBR

in SWAN
two manifestations related to one expression (work)

When we import the data from PubMed, it gives a reference to a documentation.

can create an expression even if only one manifestation-- but you do not have to.

The manifestation has all the metadata, the expression is just saying these two things are the same thing

Agaric knows that the best usability would never have people entering numeric IDs into a text field in the first place, but pending fancy remote search and completion techniques, we can at least take a set of numbers without rejecting them for using semicolons instead of commas.

Exclude certain fields from Drupal search.

Agaric and Science Collaboration's real need for this is for AJAX autocompletion, the sort of function used to autocomplete taxonomy, userreference, and nodereferrence fields. It would be great not to have to create a custom indexing system each time you want autocomplete to act on certain fields.

Science Collaboration Framework (SCF) has a "node proxy" module that allows Drupal to query a SPARQL endpoint and only loads the data when someone looks for it-- at this point it creates a node.

The system isn't bad and may be a good base lacking any established best practices in Drupal for lazy loading of nodes from outside data sources.

Ontology module in SCF profile's custom modules directory, originally authored by Mark Goetz, is very close to ready to be committed to Drupal.org. It relies on Taxonomy extra (taxonomy_extra) module, originally by Alister Lewis-Bowen, and also in SCF profile's custom modules.

Make the (presently undeclared) dependency on graphbrowser module optional.

Create a similar optional dependency on gene_ontology (or move both these additions of data out of the hack of being added on the theme layer).

In on use case, feeds as nodes (with FeedAPI) causes issues with dbscripts approach to managing staging and deployment. Dev and live will pull the same content with a different IDs. In one solution, we'll have to disable aggregation on development.

Do we have a module for that? "if at this address, force this module to disabled." Not that we can find.

It is a shame this isn't part of settings.php

Here is the new approach for importing a lot of taxonomy terms:

Parse the entire file into terms and their data.

Load existing terms by name or, preferably if available, a unique ID. Process these with individual taxonomy_term_save commands (enhanced to allow custom operations via a hook). This is a big for loop.

SCF may have to move to a full Drupal distribution at some point, but for now it is a profiles directory that can be put into any Drupal 6 installation (before or after install is run).

Modules

The modules directory is currently broken down into categories.

modified

If a module is customized, modifications to a module that is available elsewhere, it should be called something else. Otherwise there are namespace conflicts, one overriding the other, and potentially breaking the dependencies for it.