RDF хэш против слов слеша (и остальные)

Я не могу понять идею в случае пространств имен и их природы хэша или слэша. Я понимаю их обоих, но я встретил еще одну запись, без хэша или косой черты. В частности, в книге, которую я читаю ("Мэннингс: связанные данные"), есть пара примеров, в которых используется небольшая схема, сохраненная в формате файла Turtle. Эти примеры используют этот префикс:

@prefix wish: <http://purl.org/net/WishListSchema> .

В результате (перевод на JSON-LD):

 "http://purl.org/net/WishListSchemwish_list_item":

В случае, когда я добавляю хеш / косую черту к префиксу, это выглядит более разумно:

 "wish:wish_list_item":

Может быть, я не правильно понимаю разницу словарного запаса / схемы, я не знаю.

Обозначение без хеша или косой черты является общим? В чем проблема?

Источник

3 ответа

Решение

Обозначения без косой черты или хеша не являются общими. Я не видел словарь, использующий это соглашение. А в рекомендации W3C они предоставляют только рецепты для косой черты и имеют URI: http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2006-01-18/

На самом деле, если вы используете тот, который указан в вашем примере, это может считаться косой нотацией, но каждый термин в вашем словаре будет начинаться с "WishListSchema_".

С точки зрения derreferenceability, этот пример также может привести к проблемам, если вы используете purl, так как вам придется создавать разные purl для каждой концепции вашего словаря. Вместо этого, если вы используете что-то вроде http://purl.org/net/WishListSchemwish вы можете перенаправить URL-адрес на ваш сервер и использовать соответствующий рецепт для публикации словаря.

Источник

Это не распространено, и это не очень хорошая идея. ИРИ становится сложнее читать. То же самое относится и к @base директива, которая действует как префикс - за исключением того, что если используемый IRI не имеет косой черты, то последний qname также удаляется:

@base <http://test.org/path#> .\n <a1> <b1> <c1> .

разбирает как личность с ИРИ " http://test.org/a1"

Может быть серьезно запутанным, и я не думаю, что это была лучшая идея для учебника.

Источник

Один из случаев, когда может появиться префикс без завершающего символа, — это когда данные изначально хранились в формате XML. RDF/XML традиционно поддерживает прямую обработку префиксов как пространств имен XML , поэтому будет объявлен как , с символом решетки.

Однако ничто не мешает объявить другие пространства имен в RDF/XML. Слишком простые инструменты могут создавать такой префикс:

      @prefix xml: <http://www.w3.org/XML/1998/namespace>

Теперь, подобно XML, пространство имен в RDF представляет собой просто абстрактную группу связанных ресурсов, но, в отличие от XML, оно нигде не объявляется в самих данных RDF. Он просто возникает, когда человек проверяет префиксы, но он не существует сам по себе.

Пространства имен становятся важными, когда вы действительно хотите, чтобы URI имели значение — когда ресурс является частью группы связанных ресурсов (например, онтологии), а URI должен быть разыменован. Соглашение о хэше или косой черте — это просто самый простой способ настроить веб-сервер, чтобы это стало возможным. Если кто-то настраивает свой веб-сервер для обработки любого URI, начинающегося точно с что касается этого пространства имен, с этим также не будет проблем.

Как я заметил, я не думаю, что это прямое преобразование из пространств имен XML когда-либо было удачным. Пространства имен XML также не были обязаны быть разыменованными, но они никогда не рассматривались как префиксы ни в каком контексте, так что если есть лишь небольшой шанс, что описывает что-то (здесь это действительно так), то никогда не может иметь смысла. На мой взгляд, более разумным алгоритмом было бы проверить, заканчивается ли пространство имен на или (что редко встречается в XML, за интересным исключением ), и добавить если это не так. Вы, конечно, не получите 404 при поиске этого.

Источник
Другие вопросы по тегам