>
> > One can always use the talk page, like with all the templates
> > documenting usage and monitoring.
>
> True. With additional benefit that you can use nice templates like
> SPARQL and SPARQL2 to display the queries.
>
talk page templates are definitely a valid alternative. The main benefit I
see in storing SPARQL query examples via a property of a property is that
they'd become discoverable via SPARQL themselves, so for example you could
allow users to find interested queries limited to a set of properties with
given characteristics (basically allowing filtering on all properties of
properties).
Might be nice, but we need a good way to present the query in the UI (see
> below).
>
Agreed. I imagine, from a design perspective, these "helper" properties
(like P1855) that are not really part of the data model could be grouped
together and presented via a dedicated UI element, like we do for
identifiers.
> > I think it may be a good idea to start thinking about some way of
> > storing queries on Wikidata maybe? On one hand, they are just strings,
> > on the other hand, they are code - like CSS or Javascript - and storing
> > them just as strings may be inconvenient. Maybe .sparql file extension
> > handler like we have for .js and .json and so on?
If you could store queries, you could also store queries for each item that
> is about a list of things, so that the query returns exactly the things
> that should be in the list ... could be useful.
I hadn't thought of this use case, but I too see how it might be useful.
Are there other good examples of properties that take code snippets as a
value?
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
