taxonomy

Hi,

Been trying to find a way to use taxonomy to create "automatic" children.

Basically I am working on a site that will display content based on location. So there will be a taxonomy with this kind of structure:

• Country
  • Region
    • City

Overview: Views have only used minimal amount of the power of taxonomy. Some of the rich feature of taxonomy were never explored. This is a project to implement some codes to make views do more with taxonomy.

Description:
Currently, the only thing we can query about taxonomy in views are.

• Is one of a set of terms
• Is non of a set of terms
• Is all of a set of terms

There is no support of term relations at all.
If a node N is associated with term A and B, where B is a child of A, then the user might only tag the node with B. With the current views, a user specifies to select nodes associated with A, N will not show up. Thus is one of all children/ direct children comes in handy.

With this idea in mind, I believe here are some features might be awesome for views to have

• (Is one of/Is non of/Is all of) + A term + (all parents /direct parents /all children /direct children /related)
• (Is one of/Is non of/Is all of) + few terms + (Union/Intersection of)+(all parents /direct parents /all children /direct children /related)
• When those are not enough, more complex taxonomy queries can be made in views. Only a query language based on term/term will be implemented. (i ('triangle' 'ellipse') (! (p 'circle'))) means return terms 'triangle', 'ellipse' that is not a parent of 'circle'. The returned terms can then be used to find nodes, perhaps though tql, which is a query language based on term/node relation.

The all parents and direct parents functions can be replace by a nth level parents function, gives it more functionality.

Here is a description of the query system and what will be achieved.

The query system can take the full power of the taxonomy system and return all the terms(not nodes, but could be extended to nodes) meet the specific requirement.  The syntax is lisp like, but different keywords.

There will be 3 stages in the query system. One must be completed in order to work on the other. User can chose which stage to activate in module administration.

STAGE 1. Relational select.

This stage only supports queries based on taxonomy relations. The result of a query is a list of term(s).

During stage 1,There are only 2 types of manipulate-able data. list(of terms), terms(or negative terms).

Here are some functions.

Basic structure

• 'term name' returns 1 or a list of terms with "term name" as it's name
• ('foo' 'bar') is a list, list a can contain terms or more lists. Each element is separated by space
• 1 this is a integer, in stage 1, it is the same as return a term with id 1.

Selection functions

These functions are kept to be minimal in size, because these are the ones most likely to be used.

• term return the term.
• (c term) returns all direct level children.
• (c list) (c term term term) is the same as ((c term) (c term) (c term))
• (p term) returns all direct level parents.
• (p list) (p term term term) is the same as ((p term) (p term) (p term))
• (r term) returns all related terms.
• (r list) (r term term term) is the same as ((r term) (r term) (r term))
• (| list) (u list) union lists of terms, also works as 'or' in conditions
• (& list) (i list) find the intersection of lists of terms. , also works as 'and' in conditions
• (! list) (n list) turn every term in the list to it's negative counter part. For a term, it return negative term. For a non-zero integer, it returns integer * -1. For 0, it returns 1. so it can be used as not in conditionals.
• (lca list) Lowest common ancestor of all terms in the list. This is a example of higher level functions in stage 1, more will be implemented, for efficiency reasons.

This set of functions is enough to select any possible set of terms though term relations. Efficiency is the main concentration.

For any function in stage 1, it's ok to have multiple list as inputs, it will flatten and join all the lists. u( p('foo' 'bar') 'bar2') is the same as u( (p('foo' 'bar') 'bar2'))

Stage 2. Conditionals and loops

Stage 1 should be good enough for most people, considering entering stage 2 will make the query language enough to do programs.

Conditionals and loops

• (> int int) first integer larger than 2nd integer, return 1, else 0
• (< int int) first integer smaller than 2nd integer, return 1, else 0
• (<= int int) first integer smaller than or equal to 2nd integer, return 1, else 0
• (>= int int) first integer larger than or equal to 2nd integer, return 1, else 0
• (/= int int) (!= int int) first integer doesn't equal 2nd integer, return 1, else 0
• (if int list list) if 1st integer > 0, do the 1nd list, else do the 2nd list.
• for and while loops.

Stage 2 functions

• (is_child list list) return 1 if every term in list 1 is the child of every term in list 2, else return 0.
• (is_parent list list) (is_parent a b) is same as is_child(b a)
• (is_related list) return 1 only if each term is related to all other terms in the list.
• (is_sibling list) (is_sibling a) is the same as (if (> (size (i (p a))) 0) 1 0)

• (size list) return a list of number in the list.
• (rsize list) return the total number of terms in the list, it runs recursively.
• (+ list) (- list) (* list) (/ list) (% list) basic arithmetic functions.

A possible example of return all terms under "triangle" with more than 3 children.

It's possible all the condition and loops be replaced by a sugarcoat of SQL WHERE.

If it's the latter, everything in the conditionals and loops list will be replaced by (w string), where here string can be a SQL WHERE statement.

Stage 2 allow a new type, integer. There is no distinction between term and integer in representation.

STAGE 3

During stage 2, it will support more than queries involve on calculations of taxonomy relations. It will work on other taxonomy data, like name and description. It can also some useful function will be made into the system. Include a new type string, and possible uses for it. For example, return terms starts with letter "c" and is a child of "animals" will be possible. It could be merged with stage 2 if SQL WHERE statements are more efficient.

Why is the query language useful?
The query language is not useful for small, tree-based, not-well-structured taxonomy. But when there is any taxonomy having terms with multiple parents, the query language can show it's power.
If a person want a wine that is both "Loire" and "White Wine", he can select the children of the common children of "Loire" and "White Wine". In this case, it returns any node tagged with "White Loire". Suppose a user enjoys "White Loire" and "Semillon". He want to find any other wine to drink. It's reasonable to say there could be some common property of those 2 wines made the user like them. So the user can use the lowest common ancestor(LCA) function. LCA finds the nearest common parents for both terms, which can be considered as the common property of both terms. LCA of those 2 terms will return "White Wine", and the user then can browse other terms in "White Wine" and might find something he likes. The query can become complex. Users who don't like "Loire" but enjoy "White Wine" can return only terms that are children of "White Wine" but not "Loire", unless it's both "White Wine" and "Loire". That query can be written intuitively as (u (i (! (c 'Loire')) (c 'White Wine')) (i (c 'Loire' 'White Wine'))).

Rough timeline

Starting from the coding day:

1st week of coding: Complete all taxonomy query operations for views described in the proposal. This does not include the query language.

2nd week: start implementing stage 1 of the query language

1 week before mid-term: complete stage 1 and make sure stage 1 system works correctly.

just before mid-term: make the decision on how to implement stage 2 and 3.

after mid-term: implement stage 2 and 3.

1 week before August 10th: integrate the query language with views + work on documentation

August 10th to 17th: fix bugs, do some tests and set up a demo site.
Mentors:

• randommentor0 - Anyone interested to be my mentor?
• randommentor1 - backup mentor, will help with coding standards, etc.
• ALocalMentor - I will be in US only till middle of July, and I will be in China for the rest of the summer.

Difficulty: medium

Introduction

Taxonomy is Drupal's well-known classification system. It is both powerful and outdated. As chx put it: "Taxonomy is beyond saving.". Taxonomy is slow, doesn't use modern APIs like FAPI and it needs Field integration. Updating existing code would be a long and painful process, since so many things need to be changed: all sorts of code needs to be cleaned up, Field integration, Node.module independency, etc.

Proposal

Official proposal at GSoC.

Introduction

I'd like to seed a discussion on Contextual overrides for views 2 module, a possible extension to the Interests module (Which i originally developed while working at Agileware and still partly maintain). I would also like to point out contextual based modules already exist, but they are not what this module has in mind.

To give some background on the idea...

I am currently creating a web page for a schools district webpage. I have set up a couple of drupal sites now and am curious about how to set this one up. I want to create basically 4 sites on one domain. The main page would be the district web home page. The other 3 schools need there own way of content. For example, I need to make a multi-selectable event calendar that posts to the district and the elementry. I need to know if I should use categories and taxonomy or do I need to make multisite type configuration.

Hey there.

I'm working on building a drupal six uber-cart store. It's been a fun adventure thus far.

Anyways, I'm working on building a basic store "foundation" that I can sort of use to build into any other store. I'm setting up some views blocks which display all the brands the store carries (a view), the latest products to add to the store, and the most popular items (based on views). That's all easy and works fine.

I'm having a bit more of an issue working on creating a view that displays the "product" vocabulary like this:

<

ul>

<

ul>

Hallo, liebe Gemeinschaft,

I remember hearing talk about the need for a new database field to be added to Drupal core taxonomy.module's term_data table to stash the GUID/UUID/URI associated with a term. This was particularly relevant for sharing/importing/exporting taxonomies and using standard vocabularies. I suspect it also has relevance to RDF, but my comprehension is still a bit hazy on it.

OpenCalais calais.module adds a column 'guid' to the term_data table. I can't imagine that there would be any collision risks if other modules insert in this field as well for their own vocabularies.

Hi all,
I am a researcher from DFKI in Germany and we (under leading of Leo Sauermann) are currently working on a project called OrganiK which aims to research and develop a semantic web 2.0 (social, semantic, 2.0) knowledge management system for SMEs.