Войти
А права Expression Language или REL является машинно-обрабатываемый язык, используемый для выражения прав интеллектуальной собственности (например, авторское право) и другие условия для использования по содержанию. REL могут использоваться как отдельные выражения (т. Е. Метаданные, используемые для поиска, отслеживания совместимости) или в системе DRM.
REL могут быть выражены на машинном языке (таком как XML, RDF, RDF Schema и JSON). Хотя REL могут обрабатываться напрямую, они также могут встречаться при внедрении в качестве метаданных в другие документы, такие как электронные книги, изображения, аудио или видео файлы.
Известные RELs включают:
Функция REL состоит в том, чтобы определять лицензии и описывать эти лицензии с точки зрения разрешений или ограничений, которые они подразумевают для того, как затем можно использовать связанный контент.
«Лицензия» здесь может означать:
Часто выбирают использование хорошо известной лицензии из-за ее однозначной простоты: GFDL означает одно и то же, независимо от того, кто ее использует. Использование существующих лицензий также позволяет избежать проблем, связанных с увеличением количества лицензий. Также практично использовать такую лицензию и проверять, соответствует ли проект ей, не слишком понимая, какие детали это влечет за собой. Достаточно просто знать, что «GFDL приемлем для этого проекта» и «Все ресурсы в этом проекте используют GFDL». В этом смысле хорошо известные лицензии - это способ избежать необходимости использовать REL для моделирования деталей лицензии, достаточно его имени.
Несмотря на это, REL может быть полезен с этими лицензиями. Он обеспечивает машинный способ идентификации используемой лицензии, избегая проблем с именами и потенциальных двусмысленностей между «лицензией Apache» или «лицензией Apache 2.0». Авторам этих лицензий также требуются средства для описания своих внутренних данных.
Они похожи на известные лицензии в том, что они определяются перед их использованием и могут применяться ко многим экземплярам лицензирования. Их отличие состоит в том, что, поскольку они малоизвестны, также необходимо объяснить, что влечет за собой каждое из них, поскольку пользователь всегда может столкнуться с каждым из них впервые. REL предоставляет средства для этого.
Использование лицензионного контента в проекте теперь требует оценки утверждения: «Существуют ли какие-либо ресурсы в этом проекте, лицензия которых запрещает условие, которое требует проект, или требует условия, которое проект не может разрешить?». Сюда может входить необходимая возможность распространять копии проекта впоследствии или условие аккредитации на заставке, что может быть неприемлемо для некоторых проектов.
При разработке программного обеспечения с открытым исходным кодом проекты также часто создают свою собственную лицензию под собственным названием проекта, но детали этой лицензии должны быть шаблонной копией известной лицензии или даже ссылкой на эту лицензию. REL должен поддерживать это, предоставляя средства для определения лицензий путем разделения существующих лицензий на подклассы и, возможно, изменения их поведения. Многие из этих лицензий представляют собой не более чем « тщеславные» лицензии, хотя другие зависимые проекты должны иметь возможность работать с ними.
Это лицензии, которые создаются по мере необходимости для определенных частей контента или определенных конечных пользователей. Обычно это делается для того, чтобы к ним могли быть прикреплены определенные условия использования, такие как срок годности. Хотя эти лицензии могут быть основаны на стандартном шаблоне, каждая из них уникальна. Обращение к ним по имени не могло работать, поскольку не существует единого стабильного имени. Таким образом, необходимо использовать REL для выражения каждого из них в терминах его индивидуальных свойств.
Примеры могут включать ограниченный по времени контракт на просмотр спортивных телепрограмм в течение месяца, оплачиваемый действующим контрактом, и на просмотр их дома, но не на просмотр в общественном баре.
REL может удобно использовать модель Entity-Attribute-Value, как и RDF, для структурирования своего описания модели прав. Такая модель выражается в виде списков:
REL определяет наборы членов для каждой из этих трех групп и разрешенные отношения между ними. В приведенном выше примере могут быть понятия Лицензий, разрешений и распространяемых копий. Также могут быть отношения, Лицензия может выражать запреты, и отдельно может быть дано Разрешение на распространение копий.
Затем с помощью REL могут быть сделаны утверждения (они будут вне самого REL), например:
lt;cc:License rdf:about="http://example.org/licenses/distribution/"gt; lt;cc:licenseClass rdf:resource="https://creativecommons.org/license/"/gt; lt;dc:titlegt;FooCo's Distribution Permitted Licencelt;/dc:titlegt; lt;cc:permits rdf:resource="https://creativecommons.org/ns#Distribution"/gt; lt;/cc:Licensegt;
Это определяет новую абстрактную лицензию, разрешающую повторное распространение копий. Затем Works могут использовать эту Лицензию, ссылаясь на нее,
lt;pgt;This web page is licensed under lt;a rel="license" href="http://example.org/licenses/distribution/" gt;FooCo's Distribution Permitted Licencelt;/agt;.
Обратите внимание, что хотя эта гипотетическая лицензия «Разрешено распространение» была выражена с использованием Creative Commons REL, она не является лицензией Creative Commons. Он просто использует понятия «Лицензия», «разрешение» и «Распространение». Хотя это не одна из лицензий Creative Commons, определенных в этом проекте, они имеют точную общность для этих терминов: «Распространение» имеет точно такое же значение и юридическое определение между ними.
В приведенном ниже примере W3C ODRL показано соглашение (лицензия) от лица, предоставляющего право, для актива, которое может отображаться одним правопреемником (пользователем), а другим - для печати актива.
{ "@context": { "odrl": "http://www.w3.org/ns/odrl/2/" }, "@type": "odrl:Agreement", "@id": "http://example.com/policy:4444", "target": "http://example.com/asset:5555", "assigner": "http://example.com/MyPix:55", "permission": [{ "assignee": "http://example.com/guest:0001", "action": "odrl:display" }], "permission": [{ "assignee": "http://example.com/guest:0002", "action": "odrl:print" }] } Растущий интерес к гибридным веб- приложениям и совместным проектам создает спрос на объединение контента и на технологии лицензирования, которые могут это поддерживать.
Самый простой подход - объединить контент только под одной и той же известной лицензией. Однако это чрезмерно ограничительно, и многие совместимые лицензии могут разрешать объединение их содержимого. Однако трудно судить об этом, разрешено ли это и как лицензировать полученный контент. При наличии дублирующих требований или проблем с авторским левом все еще могут быть тонкости. Примечательно, что «атрибуция-совместное использование» и «атрибуция-некоммерческое-равноценное использование» Creative Commons несовместимы.
Объединение лицензий проще, если все задействованные лицензии могут быть выражены через один и тот же REL. В этом случае легче увидеть, когда применяется разрешение или запрет, если они, по крайней мере, применимы к идентичному определению «Распространение». Очевидным примером этого являются лицензии Creative Commons, где все семейство лицензий определяется в терминах одного и того же REL.
Даже если разные лицензии изначально были определены через разные REL, можно одновременно перекодировать лицензию в другом общем REL, что сделает их сопоставимыми. GPL недавно была выражена в ccREL, что дало это преимущество.
Помимо проблем с противоречивыми требованиями (см. Выше), существуют также технические проблемы при сравнении лицензий. Многие из них устраняются, если можно использовать один и тот же REL, даже если лицензии разные.
Обычная проблема семантического перевода между схемами (такими как REL) заключается в том, чтобы убедиться, что значения терминов идентичны. Хотя семантическая сеть начинает использовать инструменты онтологии, такие как OWL, для описания смысла, текущее состояние REL менее продвинуто, чем это. Более простая обработка и возможность дорогостоящего судебного разбирательства в противном случае означает, что семантика REL должна быть однозначно идентичной, а не просто предполагаемой через логика рассуждений.
Обычные проблемы заключаются в демонстрации эквивалентности классов, свойств и экземпляров. Для REL основная проблема заключается в экземплярах, т.е. точных определениях «Распределение», «Совместное использование» и т. Д. Классы и свойства обычно являются простыми понятиями и очень похожи. Однако не все REL поддерживают все классы: некоторые игнорируют юрисдикцию или даже конечного пользователя, в зависимости от потребностей рынка, для которого они были разработаны.
Менее очевидная проблема при сравнении REL - это когда у них разная базовая линия. Базовый план определяет условия, подразумеваемые лицензией, когда не включены явные заявления. Некоторые REL используют подход «Все, что не разрешено, запрещено», другие (например, ccREL) используют Бернскую конвенцию в качестве основы.
