Ваш первоначальный вопрос заставляет меня думать, что вам нужно что-то вроде Jena schemagen , которое будет автоматически генерировать коллекцию Java-констант из идентификатора URI, используемого в онтологии. Однако схема DbPedia OWL довольно велика, и я думаю, что схема может не дать полезного результата (я не пробовал). Если это так, вы всегда можете выбрать подмножество ресурсов и свойств, которые вас интересуют, и запустить schemagen для этого подмножества.
Однако ваш пояснительный комментарий, в котором вы говорите об использовании других свойств, таких как широта и т. Д., Заставляет меня думать, что вы задаете другой вопрос, а именно: как избежать того, чтобы конкретные свойства были жестко запрограммированы в запросах SPARQL. Является ли это проблемой для вас, полностью зависит от проблемы, которую вы пытаетесь решить, и архитектуры вашего кода. Для программы вполне возможно поддерживать множество строк запросов SPARQL и просто выбрать ту, которая ей нужна для конкретной работы. Это обычный шаблон использования.
Однако существуют законные случаи использования, когда вы хотите взять общую строку запроса - например, select * where {?s ?p "foo"} - и убедиться, что одна из переменных заранее привязана к определенному значению. Хотя это можно сделать с помощью манипуляции со строками, есть более элегантный способ. Например, чтобы взять вышеуказанный запрос и предварительно связать ?p со свойством dc:creator, вы можете сделать:
String q = "select * where {?s ?p \"foo\"}";
QuerySolutionMap qsm = new QuerySolutionMap();
qsm.bind( "p", DC.creator );
Query query = QueryFactory.create( q );
QueryExecution exec = QueryExecutionFactory.create( query, model, qsm );
ResultSet rs = exec.execSelect();
См. Также эту запись в блоге для получения дополнительной информации или JavaDoc .