Edit Content OP Proposal Review Edit Form: Reviews:TimLebo about LicenseLinkedDataResources

From Odp

You have to log in to edit pages.

Warning!

Note that each Review is related to the version of the Content OP Proposal's page in the moment the review's page is created the first time. Edit this page only if you want to change, add or clarify the review. In general, better you do a new review, instead of editing this page.

Change review

Input your review in the fields below. If you are unsure of the meaning of the fields, click on the question mark to get an explanation.

The "overall suggestion" should reflect your overall suggestion for this submission, and should be motivated in the responses to the review questions.

Try to cover as many of the aspects as possible, and if applicable give detailed suggestions to the author how to improve and revise the submission.

Thank you for contributing!

Overall suggestion (score) info.png (-1) : This is not an appropriate submission, in case the author wishes to revise it a new submission is needed => suggest to reject it! (0) : The submission needs a major revision to be certified, the author should revise it and ask for a new review => suggest to reiterate with new reviews! (1) : The submission needs a minor revision to be certified, after revision the pattern can be certified without a new review (reviewers should give detailed recommendations) => suggest minor revision! (2) : The submission is ready for certification => suggest accepting it for certification! :
Review Summary info.pngSummarize the main points of your review here. Make sure to motivate the overall score, and if you have any direct questions to the author please state them here. This field is associated with the property This is a property of type Text. :	There is currently no good solution to describe how information resources on the web can be used by the variety of consumers that may or may not be able to use them in certain ways. The LLDR pattern proposes to describe what rights certain agents have to perform certain acts on linked data resources (datasets, statements). The pattern incorporates some terms from existing popular vocabularies (DCTerms, VoID, CC, FOAF, ACL), but the "core three" properties hasObject, hasRight, hasSubject are too poorly defined to inspire adoption. Besides some practical issues such as comments in the ontology, inconsistent namespacing, lack of resolvability, and prefix ambiguity and confusion, this pattern should be revised to adopt one of two perspectives: * Use OWL to do reasoning (instead of just specifying the structure) * Use the Directed Qualification Pattern (instead of the more ambiguous n-ary pattern) These two are described in more detail below.
Reviewer Confidence info.pngPlease describe your confidence with respect to different aspects such as ODPs in general, the problem addressed, and the domain of the pattern, rather than giving one overall assessment. This field is associated with the property Property:HasReviewconfidence :	Have reviewed hundreds of OWL ontologies and adopt portions in dozens of Linked Data modeling projects.

Review the pattern "content" and input your detailed comments below:

Problems info.pngAre there any problems or even errors in the pattern? Do you have suggestions for correcting the problems? This field is associated with the property This is a property of type Text. :	6) Classes versus instances (and punning) Why does the LLDR ontology have an exemplar instance for each subclass of LinkedDataRight? When does one refer to the instance, and when does one refer to the class? When does one instantiate their own instance of the LLDR subclasses of LinkedDataRight? It would seem to me that an instance of Access is a particular occurrence of Access (say, when I downloaded your OWL file). If I did it again, I'd have another distinct instance of Access. See "Consideration of W3C PROV" for the intrinsic parallels between being permitted to do something and actually doing it (in this case, the subclasses of LinkedDataRight are prov:Activities). 9) Prefixes and namespaces The prefix "lldr" was not defined in the paper, nor at prefix.cc. I've since added it to prefix.cc/lldr. http://purl.oclc.org/NET/lldr/ns# The paper did not define the prefix "gr", which was fortunately defined at http://prefix.cc/gr. The properties "hasCurrency" and "hasCurrencyValue" in the example did not have prefixes, so I had to presume they were Good Relations properties. The namespaces in the OWL representation seem to be inconsistent. In the paper, the following classes use the same prefix, but they do not share the same namespace (http://purl.oclc.org/LinkedDataResource, http://purl.oclc.org/NET/lldr#LinkedDataRight). 10) Resolvability The following URIs are mentioned in the OWL representation but do not resolve (they 404) http://purl.oclc.org/access http://purl.oclc.org/Authorisation http://purl.oclc.org/Contract http://purl.oclc.org/derivativeWorks http://purl.oclc.org/distribution http://purl.oclc.org/extraction http://purl.oclc.org/License http://purl.oclc.org/LinkedDataResource http://purl.oclc.org/NET/lldr http://purl.oclc.org/Proposition http://purl.oclc.org/reproduction http://purl.oclc.org/reutilization http://purl.oclc.org/SimpleLicense
Community Relevance info.pngIs this pattern relevant? Does it solve an important problem of the domain? Or is it for example a trivial solution or a solution to a very specific problem interesting only to a few people? This field is associated with the property This is a property of type Text. :	I am not familiar with the licensing community, but as a member of the LInked Data community, I would say this pattern is intended to be relevant but its current design does not inspire confidence to adopt it.
Relation to Best Practices info.pngDoes the pattern represent a best-practice how to solve the modeling problem? Are there alternative solutions? This field is associated with the property This is a property of type Text. :	4) Consideration of W3C PROV After asserting some LLDR, a natural question to ask is "did anyone violate some rights?". The only way to answer that is to know what happened. The proposed pattern offers how to model what can or can not happen, but a natural and necessary complement is to also model what happened. Within Linked Data, the ontology to model what happened is undoubtedly W3C's PROV Recommendation. While one could claim that PROV integration with LLDR is "future work", would it not be better to phrase LLDR in terms of PROV in the first place, so that rights violation would be a simple matter of querying the same concepts under some addition constrains provided by LLDR? See comment "Use of Reasoning" below. 3) Level of reuse The proposal claims value in LLDR by its "reuse" of existing vocabularies CC, FOAF, ACL, DCTerms, and VoID. However, it does not provide reassurance that each is being reused acceptably according to the original ontology. It also does not provide justification for why the remaining portions of the reused ontologies are not also used in this pattern. So, I am forced to do so here to gain the confidence that I should be provided by the proposed pattern and its description. ACL is reused by grouping acl:Access as a lldr:LinkedDataRight. But, why was acl:Authorization and acl:InformationResource not reused by LLDR? They both seem to apply to your requirements. acl:Authorization is either a subclass of lldr:RightsExpression or is equivalent. lldr:LinkedDataResources are acl:InformationResources, and the LLDR pattern should apply more generally to the latter. CC is reused by cc:License, cc:Requirement, cc:Permission, cc:Prohibition, cc:requires, cc:Reproduction, cc:Distribution, and cc:DerivativeWorks. The ontology does not mention cc:requires, although it appears in the example in the paper. The paper diagram shows that cc:Requirement is a subclass of lldr:RightsExpression, but cc:Requirement does not appear in the OWL. The comment on lldr:Reutilization sounds a lot like its superclass cc:Distribution, what's the difference? Do cc:Reproduction,Distribution,DerivedWorks not relate to cc:Permission,Requirement,Prohibition in the CC ontology? I find it hard to believe that they'd be isolated, but cannot spend the time to dig into CC for this review. I will omit a complete comparison to CC in this review, but it should be done by the authors. FOAF is reused by using foaf:Agent. Although this is a straight forward choice, the FOAF definition is known to have problems when using it to perform reasoning. VoID is reused because LLDR only applies to LinkedData resources and VoID is the primary way to talk about RDF datasets. But, since LLDR is a "pattern", it should apply to any kind of information resource (like ACL's) and not just linked data. DCTerms is reused by dcterms:license. It's not clear how this is a part of the pattern. However, if the directed qualification pattern were used, the relation between dcterms:license and a RightsExpression would make perfect sense. See comment "Qualification pattern". In this case, RightsExpression would be a subclass of rdf:Statement with restriction onProp rdf:predicate value dcterms:license. With this, you'd be qualifying the license of the resource with respect to the agent, use, etc.
Reusability info.pngIs the pattern reusable in many situations, or is it very specific? Also related to relevance (see above). This field is associated with the property This is a property of type Text. :	It is too specific to Linked Data resources when it could apply generically to any information resource. More comments below.
Relations to Other Patterns info.pngIs the pattern related to other patterns? Are there similar patterns already in the catalog? In other domains? This field is associated with the property This is a property of type Text. :	7) Qualification pattern It should be noted that the n-ary relation pattern is also known as the "Qualification pattern" (as discussed at http://patterns.dataincubator.org/book/qualified-relation.html). In addition, an emerging "triple-oriented" qualification pattern can be seen as a more natural n-ary relation modeling for Linked Data and the semantic web, since the relation class is implicitly reifying a particular triple instead of just "wrapping a bunch of resources" into a single ambiguous relationship. This pattern can be seen for arbitrary properties in SIO (https://code.google.com/p/semanticscience/wiki/SIO - sio:has-attribute, sio:Attribute, sio:refers-to) and for particular properties in W3C PROV-O (prov:qualified*, prov:Influence, prov:{entity, agent, activity}).

Review the pattern "presentation" and input your detailed comments below:

Overall Understandability info.pngIs the pattern easy to understand from the description? Are all details of the pattern clear? This field is associated with the property This is a property of type Text. :	2) Definitions of new concepts The primary terms lldr:RightsExpression, lldr:LinkedDataResource, lldr:LinkedDataRight, lldr:hasSubject, lldr:hasRight, and lldr:hasObject are not given a natural language definition in the paper. While RightsExpression is given a good natural language definition in the OWL representation, and lldr:LinkedDataResource and lldr:LinkedDataRight are self-explanatory, the peculiar properties lldr:hasSubject, lldr:hasRight, and lldr:hasObject do not have any natural language comments. These three properties are by far the weakest part of the pattern because they are so poorly defined; they seem only to be "defined by example." And, unfortunately, they are the crux of the pattern. See comments "Use of Reasoning" and "No concrete examples" below. Looking at the subclasses of lldr:LinkedDataRight, what is "Linked Data" about it? It appears as though it should be more generally named lldr:Right, which would parallel your lldr: RightsExpression much more naturally and permit application to resources beyond your lldr:LinkedDataResources. Does the diamond in the UML diagram between RightsExpression and License/Contract indicate aggregation? Nothing is defined in the OWL representation except for a subclass relationship. This seems to be contradictory. 12) Approachability for a licensing novice The pattern proposal and description does not provide enough background information about the licensing domain to enable an expert OWL and Linked Data developer to apply the concept. Granted, licensing is a challenging topic, but the pattern should include at least a primer and pointers to authoritative resources that outline the challenges and best practices for licensing practitioners.
Clear Problem Description info.pngIs the problem description clear? There should not be any uncertainty as to what problem the pattern solves and under what conditions it is applicable. This field is associated with the property This is a property of type Text. :	The problem description was very broadly stated, and the "definition by examples" were insufficient to clearly show how they addressed each of objectives stated.
Clear Relevance and Consequences info.pngIs the relevance of the problem clear from reading the problem description, and are consequences of using the proposed solution stated? This field is associated with the property This is a property of type Text. :	8) Use of reasoning Despite being a submission to the Ontology Patterns community, the LLDR proposal does not use any "useful" inference. The only inferences that are used define the structure that should be followed for assertion (and even that is incomplete and not usable). OWL allows us to share domain knowledge by exchanging domain-independent axioms that permit a non expert to determine what inferences can and should be applied to understand the domain. This is not the case for LLDR. The proposal provides merely terms and does not leverage any OWL reasoning to facilitate the understanding of the domain it is modeling. For example, "can not be used" is expressed in OWL using a restriction such as "max 0 on prov:used" and "obligated" is an inference in the form "If one does X, Y must also occur". This can be modeled in OWL, but I'm not going to provide the solution in this review. A satisfying solution for modeling the License of Linked Data Resources would be to provide axioms over the PROV notions of Agents, the kinds of Activities they perform (such as Distributing), and their use and generation of Entities (Works, Licenses, etc). See comment "Approachability for a licensing novice" below.
Clear Figures and Illustrations info.pngAre examples, figures and other illustrations of the pattern clear and relevant? Are notations explained (if non-standard)? This field is associated with the property This is a property of type Text. :	Does the diamond in the UML diagram between RightsExpression and License/Contract indicate aggregation? Nothing is defined in the OWL representation except for a subclass relationship. This seems to be contradictory. The paper did not define the prefix "gr", which was fortunately defined at http://prefix.cc/gr. The properties "hasCurrency" and "hasCurrencyValue" in the example did not have prefixes, so I had to presume they were Good Relations properties. The namespaces in the OWL representation seem to be inconsistent. In the paper, the following classes use the same prefix, but they do not share the same namespace (http://purl.oclc.org/LinkedDataResource, http://purl.oclc.org/NET/lldr#LinkedDataRight).
Missing information info.pngIs there any information missing about the pattern? This field is associated with the property This is a property of type Text. :	1) Compared to related RELs The paper claims that the proposed pattern is conceived by extracting commonalities among the well-known Rights Expression Languages, but does not provide even a sketch of the mapping between the proposed pattern and the essential concepts in each of these other languages. In addition, the paper does not indicate the shortcomings of the well-known RELs or the advantages that the LLDR pattern provides. Why not just use the existing and well-known languages? 5) Relationship to Planning The research topic of AI planning centers around conditions and consequences, and seems to be extremely relevant to your concepts and requirements. The LLDR ontology should be compared and contrasted with this body or related work. 11) No concrete examples There should be concrete RDF/OWL examples available to illustrate each term proposed in the ontology. There are no examples provided. Beyond examples for illustration, where are the real examples of this pattern being used in the wild? In Linked Data, that should be easy to fulfill, since it can just be done and one can point to them. If there hasn't been a need compelling enough to actually solve a real problem, then is the pattern truly simple, useful, and worthwhile enough for others to adopt?

Edit Content OP Proposal Review Edit Form: Reviews:TimLebo about LicenseLinkedDataResources

From Odp

Views

Personal tools

Navigation

Contribute

Help

Catalogues

Quality Committee

Content OP publishers

Editorial Board

Administrator

WOP

Search

Toolbox