There's been a little bit of discussion about this, but not a huge amount.
I'm inclined to propose adoption of existing Dublin Core terms where appropriate, in particular those which are in relatively wide use. However, the directionality of these terms and of ODRL 'target' are opposed to one another. This isn't a problem, necessarily, it just needs to be bottomed out.
So, my questions for the group:
1. Would it be valid to say that odrl:target is an inverse of dcterms:license or dcterms:rights ?
I'm not convinced by this: my reading of the model suggests that odrl:target is a fairly generic linkage mechanism between *some facet* of the policy and the asset; in contrast, one of dcterms:license or dcterms:rights would only be valid where a linkage is required between the whole policy and the asset, which is a very useful shortcut (particularly in open licensing scenarios), but not the extent of ODRL's capabilities.
Perhaps, given that, one could define an anonymous property which is defined as both a superproperty of one of dcterms:license or dcterms:rights, and also the inverse of odrl:target. Would that work?
(It's slightly messy, but I'm keen to retain the flexibility inherent being able to use the DC terms for the 'easy' cases while being able to fall back to odrl:target for more complex expressions)
Thus:
:target
a rdf:Property , owl:ObjectProperty ;
rdfs:subPropertyOf :relation ;
vs:term_status "testing" ;
rdfs:label "Target"@en ;
rdfs:comment "The Asset upon which the Action is performed."@en ;
rdfs:domain :Action ;
rdfs:range :Asset .
_:superRights
a rdf:Property ;
owl:inverseOf :target ;
dct:rights
a rdf:Property ;
rdfs:subPropertyOf _:superRights .
I'm open to suggestions for a better way of doing this!
2. In either case, which of dcterms:license or dcterms:rights is more applicable?
dcterms:license is defined as
?A legal document giving official permission to do something with the resource.?
Furthermore, http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#dcterms:license provides the example:
ex:mySoftware dcterms:title "GeoNetwork - Geographic Metadata Catalog" ;
dcterms:license <http://www.gnu.org/licenses/gpl.html> .
<http://www.gnu.org/licenses/gpl.html> rdfs:label "GNU General Public License" .
Meanwhile, dcterms:rights is defined as
?Typically, rights information includes a statement about various property rights associated with the resource, including intellectual property rights.?
While http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#dcterms:rights provides the example:
ex:myDocuments dcterms:title "Diaries of Juanita Ramirez"
dcterms:rights _:accessConditions
_:accessConditions dcterms:title "Access to my stuff"
dcterms:description "Resources under this right can only be read, searched and
used by members of the myProject" .
The respective ranges of the two are:
dcterms:LicenseDocument:
?A legal document giving official permission to do something with a Resource.?
dcterms:RightsStatement:
?A statement about the intellectual property rights (IPR) held in or over a Resource, a legal document giving official permission to do something with a resource, or a statement about access rights.?
It seems to me that dcterms:RightsStatement is generally a superset of dcterms:LicenseDocument, and consequentially dcterms:rights similar constitutes the more generic term. In the context of ODRL, the definition of 'rights statement' seems more appropriate given that ODRL is a more full-featured REL than one which only allows the expression of already-granted permissions.
Looking around, it seems the Government Linked Data group (amongst others) reached more or less the same conclusion:
https://dvcs.w3.org/hg/gld/raw-file/default/dcat/index.html#Property:catalog_rights
Any thoughts?
M.
--
Mo McRoberts - Analyst - BBC Archive Development,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
MC3 D6, Media Centre, 201 Wood Lane, London W12 7TQ,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------