El carácter # se añade al final de una URL para indicar un fragmento o ancla en una página web. Así lo deja caer el RFC 1738 (página 2), la especificación oficial del protocolo URL:

The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it.

Esta es la referencia más clara al operador # que se hace en el documento, y, como se puede ver, no especifica cuál ni cómo debe ser el uso del operador, sino que simplemente nombra el uso que se le está dando, ya que el párrafo explica la codificación de caracteres.

Si buscamos información en fuentes no tan "oficiosas", la Wikipedia nos dice que una URL tiene la siguiente estructura:

esquema://autoridad/ruta?consulta#fragmento

El fragmento identifica a una porción de un recurso, habitualmente una ubicación en un documento.

Nada nuevo de momento. Pero la enciclopedia colaborativa añade:

La parte #enlace, por último, es conocida como identificador de fragmento y se refiere a ciertos lugares significativos dentro de una página; por ejemplo, esta página tiene enlaces internos hacia cada cabecera de sección a la cual se puede dirigir usando el ID de fragmento. Esto es relevante cuando un URL de una página ya cargada en un navegador permite saltar a cierto punto en una página extensa.

Y también interesante:

Dado que el protocolo HTTP permite que un servidor responda a una solicitud redireccionando el navegador web a un URL diferente, muchos servidores adicionalmente permiten a los usuarios omitir ciertas partes del URL, tales como la parte "www.", o el carácter numeral ("#") de rastreo si el recurso en cuestión es un directorio. Sin embargo, estas omisiones técnicamente constituyen un URL diferente, de modo que el navegador web no puede hacer estos ajustes, y tiene que confiar en que el servidor responderá con una redirección. Es posible para un servidor web (pero debido a una extraña tradición) ofrecer dos páginas diferentes para URL que difieren únicamente en un carácter "#".

En conclusión, el uso del operador # no está regulado ni normalizado, y es un estándar de facto únicamente en el protocolo HTTP, donde se le da un uso concreto: saltar a un marcador dentro de la propia página. Para ello está la etiqueta HTML <a name="nombre_marcador"></a>, aunque el comportamiento se implementa en el navegador, por lo que no es obligatoria otra llamada al servidor. No obstante, los servidores web pueden modificar ligeramente su comportamiento.

Hackeando el operador en AJAX

Hasta hace poco, éste era todo el uso que se le daba al marginado operador #: saltar a otros "marcadores" internos dentro de una página web. Hoy en día, el operador # se utiliza en combinación con JavaScript en interfaces web basadas en AJAX, donde en una sóla página (es decir, sin cambiar la parte esquema://autoridad/ruta?consulta de la URL) se producen múltiples acciones. Y se utiliza precisamente para cambiar la URL aunque el navegador realmente no recarge la página entera, consiguiente así dos interesantes detalles relacionados con la usabilidad:

• La posibilidad de usar las funciones "Atrás" y "Adelante" del navegador.
• La posibilidad de identificar inequívocamente una sección de la página y poder enlazarla o guardarla como favorita.

Hoy en día este comportamiento se puede comprobar en sitios como GMail o Facebook. Por ejemplo, si entramos en http://www.facebook.com/home.php, tenemos la página principal. Si queremos subir un vídeo, pulsamos el enlace correspondiente, el cual cargará la interfaz a través de AJAX. Si quisiéramos enviarle a un amigo la dirección para subir vídeos en Facebook, tendríamos que indicarle que fuese a http://www.facebook.com/home.php y, una vez allí, pulsar en "Subir vídeo". Gracias al operador #, no es necesario, ya que el enlace que pulsamos "Subir vídeo", además de contener un atributo onclick que cargue la interfaz de subida de vídeos a través de AJAX, es un enlace que apunta al marcador #/video/?upload, obteniendo así la URL http://www.facebook.com/home.php#/video/?upload sin haber prescindido de AJAX ni haber recargado al completo la página.

¿Hay vida más allá de HTML? I have a dream...

Como ya se ha indicado, el uso del operador # en las URL se reduce prácticamente a HTML. Y es lógico, ya que su uso no está normalizado y su utilidad en HTML es bastante reducida. En una web pensada para una lectura natural (humana), saltar a diferentes partes de la página nos puede resultar cómodo, pero no es muy útil desde el punto de vista puramente tecnológico.

Más allá de esta aplicación, las tecnologías semánticas, concretamente RDF, hacen uso extensivo de las URL (mejor, dicho de las URI) y del operador #. Un ejemplo es este encabezado RDF en el que se especifican los espacios de nombres XML que se van a usar en la descripción:

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cd="http://www.recshop.fake/cd#">

En este caso, el operador # no especifica ningún fragmento o ancla en los documentos referenciados. ¿Qué diferencia hay entre usarlo y no usarlo? Si probamos ambas opciones obteniendo por HTTP el documento (navegadores, wget, etc) el resultado es el mismo. Lo mismo ocurre con http://johnbreslin.com/blog/index.php?sioc_type=site#weblog, otra URL de ejemplo. Está claro que, a nivel de navegador no se está haciendo ninguna modificación del documento solicitado, como cambría imaginarse en un contexto de XML.

Pensémoslo. Sería realmente jugoso poder obtener fragmentos de un documento mediante este operador. La obtención del fragmento se podría producir en el servidor o en el cliente. Si hablamos de documentos XML, los fragmentos podrían estar expresados en XPath. Por ejemplo, supongamos un documento XML tal que:

<?xml version="1.0" ?>
<libros>
	<libro>
		<titulo>El manifiesto cluetrain</titulo>
		<autor>Rick Levine</autor>
		<autor>Christopher Locke</autor>
		<autor>Doc Searls</autor>
		<autor>David Weinberger</autor>
		<isbn>978-84-234-2693-5</isbn>
	</libro>
	<libro>
		<titulo>Organízate con eficacia</titulo>
		<categoria>Habilidades directivas</categoria>
		<autor>David Allen</autor>
		<editado>2006</editado>
		<edicion>1</edicion>
	</libro>
</libros>

...identificado por la URL http://www.israelviana.es/libros.xml. Sería fantástico poder obtener, a través de la dirección http://www.israelviana.es/libros.xml#/libros/libro/autor, una lista de autores. Este sistema podría complementar o incluso sustituir, en algunos casos, a los actuales servicios web, basados en XML y métodos remotos para obtener datos.

En fin, por imaginar que no quede...

Nota: el tratamiento que se le da en este artículo al término "vista" no es el mismo que el que se le da en el patrón MVC.

Hoy en día, muchos sitios web ofrecen la posibilidad de ver una página no sólo en HTML, sino en PDF, RTF y RSS. Y los webmasters que se quieren subir al carro de la web semántica ofrecen también la información en formato RDF.

Desde el punto de vista del HTML, el navegador interpreta las etiquetas <link rel="alternate"> como una vista alternativa del contenido (habitualmente RSS). Desgraciadamente no se usa todo lo que se debería (por ejemplo, las vistas en PDF y RTF que ofrece Joomla! No tienen su link rel, sino un enlace normal en la página). Pero ¿y por dentro del sitio web, en el CMS, cómo se implementa de una forma ordenada este modelo multivista? Propongo dos modelos, compatibles entre sí: el primero, más sencillo, basado en los motores de plantillas, y el segundo, basado en la programación orientada a objetos. Este segundo modelo se puede apoyar también en motores de plantillas, y ofrece, además, la posibilidad de implementar programación personalizada para cada plantilla. Vamos a verlo detenidamente.

Introducción a los motores de plantillas

En la creación de sitios web con motores de plantillas (como por ejemplo Smarty), la idea es separar el código (en nuestro caso PHP) de la interfaz (casi siempre HTML). La manera de usar estos sistemas de plantillas es sencilla: a través de código se extraen (de la base de datos, la entrada del usuario, etc) y manipulan los datos. Los datos se pasan de la forma más atómica posible a la plantilla, y ésta es un documento HTML con una sintaxis especial que permite imprimir el valor de esas variables e implementar una lógica sencilla.

Por ejemplo, este blog se apoya sobre Smarty. El script index.php extrae de la base de datos los últimos post y guarda los datos en un array multidimensional, de la forma:

Como podrás suponer, el código para obtener el array es bastante sencillo, ya que la base de datos almacena la información en un formato muy similar (tablas relacionales). Una vez obtenido, se le pasa la variable $post a la plantilla y se renderiza. La plantilla permite “programar” bucles para que recorra este array de posts, dándole formato a cada uno:

No es complicado entender la idea. Pongamos por ejemplo que en el blog tengo 4 páginas: index (el índice, que muestra los últimos posts), post (muestra un posts en concreto y sus comentarios), tag (últimos etiquetados con una determinada tag) y archivo (todos los posts de un mes concreto). Por tanto, tendré 4 scripts y 4 plantillas.

Una vista por cada formato

Pues bien, el patrón Multivista propone tener un conjunto de las plantillas (en este caso index, post, tag y archivo) por cada vista que queramos implementar: HTML, RSS, RDF. En el caso del formato PDF no podríamos implementarlo con este sistema, ya que Smarty trabaja sobre texto plano. Para ello usaremos el segundo modelo (orientado a objetos).

Una buena manera de implementar esto es, en vez de tener un directorio “templates” con las cuatro plantillas, crear subdirectorios en templates para cada vista, que contuviesen las plantillas:

Antes

• templates/index.tpl
• templates/post.tpl
• templates/tag.tpl
• templates/archivo.tpl

Después

• templates/html/index.tpl
• templates/html/post.tpl
• templates/html/tag.tpl
• templates/html/archivo.tpl
• templates/rss/index.tpl
• templates/rss/post.tpl
• templates/rss/tag.tpl
• templates/rss/archivo.tpl
• templates/rdf/index.tpl
• templates/rdf/post.tpl
• templates/rdf/tag.tpl
• templates/rdf/archivo.tpl

Una de las vistas podríamos llamarla "por defecto" (HTML), que se mostraría si una de las plantillas de la vista requerida faltase. Desde el punto de vista del usuario, podemos darle la oportunidad de elegir qué vista prefiere, a través de la URL:

• http://www.israelviana.es/blog/index.php?vista=html
• http://www.israelviana.es/blog/index.php?vista=rss
• http://www.israelviana.es/blog/index.php?vista=rdf

Por supuesto, el usuario no tiene que escribir manualmente la URL, sino se pueden dar enlaces para cambiar de vista. [img de joomla o plone]

En los tres ejemplos de vista que hemos puesto, todos los formatos tienen la capacidad de enlazarse entre sí: HTML con las etiquetas <link rel="alternate"> que ya hemos comentado al comienzo, RSS con los elementos link de channel y en RDF con rdf:about y otras propiedades.

Este sistema ofrece una metodología sencilla, implementable sin grandes cambios en el CMS y fácilmente escalable.

El segundo método que veremos, más complejo y potente, lo dejamos para otro día ;-)

A Google no le interesa entenderme, le basta con dominar el mundo.

Conspiranoias aparte, un buen profesor mío, Jesús Soto, ha publicado recientemente un artículo titulado "¿Te entiende Google?" en la revista universitaria de la UCAM. El artículo en cuestión viene a explicar la necesidad de las tecnologías de procesamiento del lenguaje natural en las búsquedas por Internet. Ejemplifica el problema con las herramientas de traducción automáticas Google y Babelfish y el motor de búsqueda de Google, en los que se obtienen resultados inesperados al traducir "mosca" del español al inglés y viceversa (la traducción de mosca, "fly", significa también volar), y también al buscar "mosca" (páginas sobre el insecto, la pesca con mosca, etc).

Los dos problemas que plantea son muy diferentes, aunque tienen en común la necesidad del PLN (procesamiento del lenguaje natural). No voy a discutir esta necesidad, ni tampoco los importantes avances que la investigación está logrando. De lo que voy a hablar es sobre web semántica (cómo no).

Señor Soto: de poco vale el maravilloso PLN en un buscador si no hay web semántica. Es muy sencilo: si entre nosotros y el contenido que buscamos está el buscador, debe haber un "protocolo" de comunicación entre nosotros y el buscador (PLN), pero también entre el buscador y el contenido. Dicho de otra manera, con el PLN el buscador entenderá qué es lo que queremos buscar, pero sin web semántica no podrá entender qué es lo que hay en la web. O al menos en el ideal escenario de ese futurista mundo de los agentes inteligentes que nos buscan el vuelo más barato o realizan investigaciones científicas.

Y digo poco porque efectivamente, sí hay lugar para el PLN en las búsquedas sin web semántica. Un pequeño lugar en el que el PLN es utilizado para "entender" el contenido de una web no semántica, una comprensión que se complementa con estadísticas de uso (cuántas más veces se haga click en tal enlace al buscar tal palabra, más cercano semánticamente se considera de los términos buscados) y algoritmos como PageRank. Efectivamente, ese pequeño lugar se llama Google, el buscador que el 96% de los españoles usan.

Podemos considerar esta cuestión como las dos caras de una misma moneda: si la web está escrita en lenguaje natural, y los buscadores son máquinas, o bien hacemos que los buscadores entiendan el lenguaje natural (pero no de cara al usuario, sino de cara al contenido) o que la web se adapte al lenguaje de las máquinas. Los esfuerzos de la investigación actual sobre la web semántica se centran en la realización y despliegue de tecnologías que permitan adaptar el contenido de la web actual a lenguajes formales, procesables por máquinas.

Uno pueda pensar que es mejor hacer que las máquinas comprendan el lenguaje, antes que adaptar los billones de páginas web a esta nueva tecnología. Efectivamente, las tecnologías de PLN tienen una importante función en la web semántica, sin ir más lejos adaptar parcial o totalmente los sitios web actuales a la web semántica. O, de cara al usuario, permitir búsquedas (y no sólo búsquedas, lo que suena más futurista es la idea de agente inteligente) más refinadas. Pero las apariencias engañan: cuando hemos visto a los ordenadores hacer cosas geniales es cuando hemos entendido que la máquina trabaja con una representación parcial del universo en su propio lenguaje. Por ejemplo, la programación.

Limitar la web inteligente al PLN significaría "construir sobre arena", ya que tendríamos que estar remodelando los algoritmos continuamente, y las aplicaciones de usuario final avanzarían de forma mucho más lenta.