[TYPO3-ect] Global categories startup

[Elmar Hinz]

Hi Steve,

steve ryan wrote:
> An afterthought is that the biggest downside to using the pid field is
> that is single selection only. It's not like you can hack the meta data
> without consequence either.

Right. The pid field wouldn't be a good choice. Regularly it is  used
for other types of relations i.e. to sort the ownership, to sort
translations, subprojects, etc.

> Possible to create an additional multiselect to pages but that kills one
> of the big advantages - it's already there. Possibly hack metadata on
> one of the exclude fields across all the categorised tables if you need
> to......hmmm ughh

It isn't there. You would need to extend every extension that provides a
 table  ...

> Retrofitting existing tables to a category source with MM including
> table name as a field or MM per categorised table is better design and
> performance that the old comma seperated list anyways.

Yes, I think a single table that stores table name and id for the
relations can be a clean solution. You can involve a lot of existing
extensions without direct alteration of the extensions. You need one
central module to organize all relations in the backend.

You can search all this tables in the FE by the new category sytem. For
the labels in the common result list you can use the title field
information from the TCA. Now you still need to generate the appropriate
call to the FE details view. Here we need a big configuration array that
maps our links to the single views of each extension type.

Ernesto wrote:

So maybe the idea would be simply to use the "pages" table for that. We
define a new doktype "category":

Can we create new doktypes on extension level or do we need to
hack/XCLASS core files for this?


> Nice would be a kickstarter option alongside enable fields.
> 
> I think that implementing standards like RDF resource tags is a

I needed to consult google:

<quote source="http://www.w3.org/TR/rdf-concepts/">

The Resource Description Framework (RDF) is a framework for representing
information in the Web.

RDF Concepts and Abstract Syntax defines an abstract syntax on which RDF
is based, and which serves to link its concrete syntax to its formal
semantics. It also includes discussion of design goals, key concepts,
datatyping, character normalization and handling of URI references.

</quote>

Well, this looks a number to big for my project.

> rendering function derived from many layers of your custom data model
> including categorisation, table and field meta data, ....... Certainly
> something could be built that works with the existing 'standard' tables
> page, content, news etc, recursing objects to combine custom and
> globally categorised(possibly page based) summary information for the
> RDF output.
> Without looking deeply, it appears that OWL provides for the schema for
> any sane categorisation scheme to be included in the RDF if you are keen.
> 

<quote source="http://www.w3.org/TR/owl-features/">

The OWL Web Ontology Language is designed for use by applications that
need to process the content of information instead of just presenting
information to humans. OWL facilitates greater machine interpretability
of Web content than that supported by XML, RDF, and RDF Schema (RDF-S)
by providing additional vocabulary along with a formal semantics. OWL
has three increasingly-expressive sublanguages: OWL Lite, OWL DL, and
OWL Full.

This document is written for readers who want a first impression of the
capabilities of OWL. It provides an introduction to OWL by informally
describing the features of each of the sublanguages of OWL. Some
knowledge of RDF Schema is useful for understanding this document, but
not essential. After this document, interested readers may turn to the
OWL Guide for more detailed descriptions and extensive examples on the
features of OWL. The normative formal definition of OWL can be found in
the OWL Semantics and Abstract Syntax.

</quote>

Also a heavy field. I wounder how we can boil the w3 specifications down
to something that we can implement and use.

> Other thoughts - ownership of categories. Implemented using pages, the
> backend users have a complete permissions setup for access to
> 'categories'. Front end, cruser_id could be stretched through groups to
> limit access to groups.

Give me some time to think all this ...

> 
> DAM integration..... my impression is that DAM is about managing file
> resources?????  Categorisation of file resources according to customised
> or global categories is the same as for any other table.

Yes, but DAM has already a buildin category tree, just like tt_news. If
we don't do something special the user would need to decide which
categories to use.  Hmmm ... that confuses the user ...

> 
> Tags clouds are just a style of form rendering for categorisation.
> 

Yes, all in one folder without a tree.


Thank you for all that interesting input. That helps me a lot with the
conception.

Regards

Elmar