El científico Stephen Wolfram considera que es hora de que los ordenadores tengan su propio dominio .data (.datos), que haga referencia a información pura y dura, una forma de estandarización y facilitación al acceso de datos.
Exagerado y poco práctico. Es mucho más cómodo estandarizarlo en forma de llamadas especificas. RESTful, por ejemplo, donde la solicitud de un recurso pueda demandar una salida en html (por defecto) o en json, xml, etc. Lo que falta es la difusión e implementación definitiva estándar semántico, no un protocolo estilo "la cuenta de la vieja" basada en un dominio secundario.
Ya, pero eso no interesa. Las máquinas no hacen clic en la publicidad y si a través de ese standard podemos leer los datos crudos, sería muy sencillo hacer webs basándose en los datos de otras, cosa que tampoco interesa.
Más que un dominio, lo que se necesita es una estandarización de las APIs.
#1
No interesa por otros motivos, básicamente porque no es necesario.
Hay modelos de negocio que se basan (o que se complementan) en ofrecer servicios REST o SOAP, pero pueden hacerse tranquilamente en un .com o en un .loquesea
#3 tendría la misma funcionalidad en gmail.com/data o data.gmail.com
#4 Coincido con que es innecesario, se puede solucionar ofreciendo subdominios de un masterdata.org u otro dominio con una extensión ya existente, o subdominios data.dominio.com
No conozco ningún servicio de descubrimiento que se base en un ping (método HEAD si el consumidor trabaja vía http) contra un dominio de primer nivel que puede existir o no. Si ejecuto una petición HEAD contra un dominio .data tengo que esperar y fijar un timeout, algo problemático y costoso si dependo de un error DNS. Lo normal es fijar un tiempo de espera para la obtención de los datos, no para descubrir si existen (requiría una segunda petición). Si lo incorporo dentro de HTML me basta con analizar una página que sé que existe (no dependo de un error). Si quiero prescindir del análisis de la página para no depender de su descarga previa -aunque se parcial-, lo más cómodo sería incorporarlo a las cabeceras http o con un fichero en la raiz del servidor (algo similar al robots.txt). De hecho, ahora que lo pienso, esto último sería lo más 'barato' y desmiente parte de lo que he dicho hace un momento (:lol:), porque el hallazgo de robots.txt sí es un servicio 'orientado a error'.
Dicho de otra forma: es como crear el dominio .rss para notificar el punto de publicación de los feeds. Amén de los problemas habituales: ¿qué pasa cuando te mangonean el dominio .data? ¿ya no puedes proporcionar el servicio?
Implementarlo como ruta (example.com/data) o subdominio no es viable como estándar porque limitaría las
aplicaciones ya existentes (cualquier subdominio o directorio 'data' provocaría confusión).
No lo veo. Aunque la discusión me parece igualmente interesante
Parece que a lo que se refiere es que al acceder al .data no nos vendrá un churro en html si no algún otro estándard más adecuado al traspaso de datos "crudos" para su proceso (que luego los procesas como te da la gana). El que sea en web.data y no en web.com/data (o una solución similar) es simplemente por simplificar y hacerlo estándar. Es una MUY buena idea.
#6 Pero para eso ya existe el elemento LINK de HTML. El servicio de publicación de datos en bruto ya se hace hoy en día vía API, lo que falta es el servicio de descubrimiento de ese servicio (diferente en cada aplicación). Para qué reinventar algo que ya existe, un ejemplo:
#8 Pues por eso, si el .data se convierte en un estándar, será fácil "descubrir" ese servicio ya que va a estar en dominio.data, donde estarían los datos en bruto en algún formato también estándar, y se podrían procesar con las APIs compatibles que a cada cual le diera la gana.
Comentarios
Exagerado y poco práctico. Es mucho más cómodo estandarizarlo en forma de llamadas especificas. RESTful, por ejemplo, donde la solicitud de un recurso pueda demandar una salida en html (por defecto) o en json, xml, etc. Lo que falta es la difusión e implementación definitiva estándar semántico, no un protocolo estilo "la cuenta de la vieja" basada en un dominio secundario.
Ya, pero eso no interesa. Las máquinas no hacen clic en la publicidad y si a través de ese standard podemos leer los datos crudos, sería muy sencillo hacer webs basándose en los datos de otras, cosa que tampoco interesa.
Más que un dominio, lo que se necesita es una estandarización de las APIs.
#1 quizá si interese porque se pueden dar servicios con eso: solo se puede acceder si tienes un login comprado en otra parte. Por ejemplo.
#2 no sería mala idea: gmail.data
#1
No interesa por otros motivos, básicamente porque no es necesario.
Hay modelos de negocio que se basan (o que se complementan) en ofrecer servicios REST o SOAP, pero pueden hacerse tranquilamente en un .com o en un .loquesea
#3 tendría la misma funcionalidad en gmail.com/data o data.gmail.com
#4 Coincido con que es innecesario, se puede solucionar ofreciendo subdominios de un masterdata.org u otro dominio con una extensión ya existente, o subdominios data.dominio.com
No conozco ningún servicio de descubrimiento que se base en un ping (método HEAD si el consumidor trabaja vía http) contra un dominio de primer nivel que puede existir o no. Si ejecuto una petición HEAD contra un dominio .data tengo que esperar y fijar un timeout, algo problemático y costoso si dependo de un error DNS. Lo normal es fijar un tiempo de espera para la obtención de los datos, no para descubrir si existen (requiría una segunda petición). Si lo incorporo dentro de HTML me basta con analizar una página que sé que existe (no dependo de un error). Si quiero prescindir del análisis de la página para no depender de su descarga previa -aunque se parcial-, lo más cómodo sería incorporarlo a las cabeceras http o con un fichero en la raiz del servidor (algo similar al robots.txt). De hecho, ahora que lo pienso, esto último sería lo más 'barato' y desmiente parte de lo que he dicho hace un momento (:lol:), porque el hallazgo de robots.txt sí es un servicio 'orientado a error'.
Dicho de otra forma: es como crear el dominio .rss para notificar el punto de publicación de los feeds. Amén de los problemas habituales: ¿qué pasa cuando te mangonean el dominio .data? ¿ya no puedes proporcionar el servicio?
Implementarlo como ruta (example.com/data) o subdominio no es viable como estándar porque limitaría las
aplicaciones ya existentes (cualquier subdominio o directorio 'data' provocaría confusión).
No lo veo. Aunque la discusión me parece igualmente interesante
Parece que a lo que se refiere es que al acceder al .data no nos vendrá un churro en html si no algún otro estándard más adecuado al traspaso de datos "crudos" para su proceso (que luego los procesas como te da la gana). El que sea en web.data y no en web.com/data (o una solución similar) es simplemente por simplificar y hacerlo estándar. Es una MUY buena idea.
#6 Pero para eso ya existe el elemento LINK de HTML. El servicio de publicación de datos en bruto ya se hace hoy en día vía API, lo que falta es el servicio de descubrimiento de ese servicio (diferente en cada aplicación). Para qué reinventar algo que ya existe, un ejemplo:
#8 Pues por eso, si el .data se convierte en un estándar, será fácil "descubrir" ese servicio ya que va a estar en dominio.data, donde estarían los datos en bruto en algún formato también estándar, y se podrían procesar con las APIs compatibles que a cada cual le diera la gana.