Ofrecer información estructurada de los precios

[virtor]

El campo de precio se ofrece como información en texto libre, para poder trabajar con este campo sería necesario que se ofreciera la información más estructurada.

[ocorcho]

Análisis sobre algunas alternativas posibles

Es importante tener en cuenta que no existe un estándar concreto para la especificación de precios de lugares (comercios, equipamientos, etc.), por lo que la solución que se tome en este momento podría modificarse en el futuro si termina de surgir un estándar en este sentido. Algunas de las propuestas que se han hecho hasta el momento son las siguientes:

• https://schema.org/PriceSpecification y https://schema.org/price permiten especificar precios para items (por ejemplo, entradas) que se estén proporcionando en un marketplace online. Está basado en el vocabulario goodRelations y se utiliza también para la especificación de datos de contratación pública (http://contsem.unizar.es/def/sector-publico/pproc), que está siendo usado en la API de Zaragoza.
• Foursquare API (https://developer.foursquare.com/docs/venues/explore) permite explorar lugares y proporciona información básica sobre su precio. Básicamente, utiliza cuatro posibles valores, del 1 al 4, según el rango de precios de un lugar. Sacado directamente de la documentación: Currently the valid range of price points are [1,2,3,4], 1 being the least expensive, 4 being the most expensive. For food venues, in the United States, 1 is < $10 an entree, 2 is $10-$20 an entree, 3 is $20-$30 an entree, 4 is > $30 an entree.

Otros sitios como la Google Places API no proporcionan este tipo de información.

También se puede considerar la propuesta, sencilla, de @jrub en su feedback sobre el uso de la API de Zaragoza (https://gist.github.com/jrub/8707031fb834d80a7828).

[ocorcho]

Teniendo en cuenta los comentarios proporcionados anteriormente, la propuesta que puede considerarse como más adecuada es una pequeña variación sobre lo propuesto por @jrub.

"price": {
  "zaragoza-card": true,
  "fares": [
    { "@type": "gr:UnitPriceSpecification", "gr:hasCurrencyValue": "3"^^xsd:float, "gr:hasCurrency": "EUR", "fareGroup": "regular", "minSize": "1"},
    { "@type": "gr:UnitPriceSpecification", "gr:hasCurrencyValue": "5"^^xsd:float, "gr:hasCurrency": "EUR", "fareGroup": "group", "minSize": "10"}
    ....
    ]
}

[txtbits]

Teniendo en cuenta las diferentes propuestas y aportaciones hemos pensando en optar por la siguiente descripción de precios:

{
    "price": [
        {
            "hasCurrencyValue": 3,
            "hasCurrency": "EUR",
            "fareGroup": "regular",
            "minSize": "1"
        },
        {
            "hasCurrencyValue": 0,
            "hasCurrency": "EUR",
            "fareGroup": "zaragoza-card",
            "minSize": "1"
        },
        {
            "hasCurrencyValue": 5,
            "hasCurrency": "EUR",
            "fareGroup": "group",
            "minSize": "10"
        }
    ]
}

[jrub]

Así de primeras, respecto a los nombres de los parámetros, no sé si los hasCurrency y hasCurrencyValue suenan naturales en web semántica, pero para un API REST me suena mejor currency para el primero y amount, price, o fare para el segundo. También, minSize, no entendía al principio qué era relativo a grupos de personas... ¿igual algo más descriptivo como minPeople? ¿y en vez de fareGroup poner fareType?

[ocorcho]

Los de currency sí que son importantes puesto que son los que se usan también en schema.org, basado en GoodRelations, y lo usan en muchos sites de comercio electrónico. Los otros se pueden cambiar, sin problema, si resultan más intuitivos de esa manera.

[txtbits]

La información referente a los horarios queda de la siguiente manera:

"price": [
    {
        "fareGroup": "string",
        "hasCurrencyValue": 0,
        "hasCurrency": "string",
        "minSize": "string"
    }
]

A través del vector price se pueden establecer múltiples precios haciendo diferentes combinaciones con el campo fareGroup que especifica el tipo/grupo de la entrada, pudiendo establecer también diferentes precios y número de personas necesario (la entrada individual tiene valor 1) para cada uno:

• Gratuita
• Anticipada
• Taquilla
• Normal
• Grupo
• Jóvenes
• Niños/as
• Jubilados/Pensionistas
• Desempleados

Nota: Los tipos/grupos pueden incrementarse en el futuro.

Ejemplo de actividad:

{
    "id": 000000,
    "title": "Título de la actividad",
    "price": [
        {
            "fareGroup": "Anticipada",
            "hasCurrencyValue": 8,
            "hasCurrency": "EUR",
            "minSize": "1"
        },
        {
            "fareGroup": "Normal",
            "hasCurrencyValue": 10,
            "hasCurrency": "EUR",
            "minSize": "1"
        },
        {
            "fareGroup": "Desempleados",
            "hasCurrencyValue": 6,
            "hasCurrency": "EUR",
            "minSize": "1"
        },
    ],
    ...
}

Se mantienen los campos precioEntrada y comentariosEntrada a nivel de actividad permitiendo la introducción de texto libre para aquellas actividades en las que exista algún dato especial referente al precio y para aquellas actividades en las que no se pueda establecer un precio estructurado.