GitHub для обмена набором запросов SPARQL

Я использую github для обмена набором запросов SPARQL:

http://www.boisvert.me.uk/opendata/sparql_aq+.html?file=specific%20sensor.txt

В настоящее время простая работа позволяет конечным пользователям получать доступ к запросам, хранящимся в репозитории github, но в конечном итоге я хочу позволить им также изменять запросы, как с pastebin, и использовать репозиторий для лучшего управления общей системой. В идеале я хотел бы, чтобы конечные пользователи, которые могут быть не очень технически подкованными, могли вносить незначительные изменения в запросы к открытой, связанной конечной точке данных: чтобы поддерживать технологический барьер на низком уровне.

Моя проблема заключается в следующем: как лучше всего структурировать проект github и использовать API, чтобы максимально использовать доступную информацию? Я могу думать о разных моментах:

  • В настоящее время проект (https://github.com/boisvert/unshaql) содержит клиентский код и примеры запросов. Есть ли смысл создавать независимый проект (отдельно от кода веб-клиента) для запросов SPARQL?
  • Я бы использовал каталоги в проекте для классификации/пометки запросов и имена файлов для их названия. Есть ли лучшие альтернативы? Мне кажется, что иерархическая структура не подходит для тегов.
  • Когда конечные пользователи сохраняют, более простой (и более грубый) вариант — позволить им отправить свой файл только в одну ветвь, содержащую примеры. Лучше было бы разрешить им использовать свои учетные данные github для разветвления набора запросов SPARQL и редактирования своих, но с неосведомленными пользователями, как мне избежать создания беспорядка?

github github-api pastebin opendata
person boisvert    schedule 29.10.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, что обычный репозиторий Github довольно плохо подходит для такого рода контента. Если у ваших пользователей есть учетная запись GitHub, вам, вероятно, следует использовать вместо нее Gists: https://help.github.com/articles/about-gists/ Я никогда не использовал это сам, но, кажется, он идеально подходит для того, что вы планируете. Ваш сайт может стать базой данных тегов, а не списков, предоставленных пользователями. Однако это заблокирует вас в решениях, специфичных для GitHub.

Даже если вы выберете обычный репозиторий, вы не должны позволять пользователям вносить изменения в репозиторий, в котором размещен ваш код: это будет серьезной угрозой безопасности, поскольку вы не сможете контролировать те части репозитория, к которым им разрешен доступ. совершать.

Если вы настроите два репозитория, довольно просто иметь код веб-страницы в репозитории, а код автоматически фиксируется в другом репозитории (под анонимным идентификатором, чтобы вашим пользователям не нужно было создавать учетную запись github).

Также обратите внимание, что токен oauth никогда не должен храниться в общедоступном репозитории (иначе роботы GitHub сделают его недействительным в течение нескольких часов). См. Скрытие токена GitHub в .gitconfig для решения этой подпроблемы.

person Martin Quinson    schedule 31.10.2015