[Tf-curation] lindat profile mappings to VLO

Jozef Misutka misutka at ufal.mff.cuni.cz
Fri Jul 1 14:12:34 CEST 2016


2Thomas: Minor comment about the statement: even though I can see the good
intention behind the statement, I have doubts if it has any legal basis.
Moreover, from the user point of view I read the message as: "Please,
rather do not use VLO because what you see here is probably wrong."
Please *verify this information* at the original source or contact the
original provider before using any of the resources or tools described on
this page.


2Francesca: Please, file an issue at https://github.com/ufal/lindat-dspace
about exploiting the different ResourceTypes as pointed out by Thomas and
also to use proper names for them. Few references:
https://trac.clarin.eu/wiki/CMDI%201.2/Specification
https://www.clarin.eu/faq/how-do-i-point-files-im-describing-cmdi-how-does-resources-section-work
https://www.clarin.eu/faq/how-can-i-indicate-resources-described-cmdi-file-are-also-searchable-srucql


Best,
Jozef




On 1 July 2016 at 13:22, Thomas Eckart <teckart at informatik.uni-leipzig.de>
wrote:

> Hi Francesca,
>
> Any suggestion?
>> We would like to keep a common policy for all centers using the LINDAT
>> software.
>>
>
> Another thing, in the our version of LINDAT the field "Demo URL" isn't
>> generating any resource proxy in the resulting CMDI.
>> Maybe that would be a more suitable candidate ...
>>
>> See this resource and its CMDI for reference.
>> https://lindat.mff.cuni.cz/repository/xmlui/handle/11234/1-1741
>>
> "Demo URL" ("A url with samples of the resource or, in the case of tools,
> of samples of the output.") sounds indeed like a better candidate for a
> resource reference. Beyond that I can't say anything about both of your
> problems as I am not involved in the LINDAT depositing service. Maybe
> someone working on the tool can jump in...
>
> Best,
> Thomas
>
>
>
>
>
> 2016-06-30 16:47 GMT+02:00 Thomas Eckart
>> <teckart at informatik.uni-leipzig.de
>> <mailto:teckart at informatik.uni-leipzig.de>>:
>>
>>
>>         For 2) in fact what I object most is not the lack of direct
>>         download but
>>         the use of what for lindat users is dubbed "project page".
>>
>>     I agree. A ResourceProxy of type "Resource" should normally point to
>>     the actual resource (like the concrete corpus, tool, webservices
>> etc.).
>>
>>         So either we give a clear semantic to that field in our repo or my
>>         modest opinion is that I would rather see a link back to our
>>         repo on the
>>         resources icon if the vlo.
>>
>>         Once redirected to lindat-clarin or ilc4clarin, users can see
>>         all info
>>         including the license and download if the have the permission.
>>         What is your opinion of this solution?
>>         I saw other repos do this...
>>
>>     That is definitely one way to do it and already more helpful for the
>>     end user as the status quo for "Deltacorpus 1.1".
>>
>>     Nonetheless, I think that this not a good solution: the CMDI
>>     specification allows 5 types of ResourceProxys. A reference to the
>>     original context of the resource in its repository is already part
>>     of it ("LandingPage"). Right now this reference may not be prominent
>>     enough at the VLO record page (maybe we find a better solution?),
>>     but it is already there.
>>
>>     The "Resource"-typed ResourceProxys are defined (at least regarding
>>     the upcoming CMDI 1.2 specification) as references to "A resource
>>     that is described in the present CMDI instance, e.g. a text
>>     document, media file or tool.". If you don't want to directly link
>>     to the actual data, I guess omitting these ResourceProxys would be
>>     the standard-compliant way to go.
>>     I personally think that direct links to the data should be part of
>>     the resource description, because it increases the usefulness of the
>>     VLO for the end user and of the resource in the context of the whole
>>     infrastructure.
>>
>>     Best,
>>     Thomas
>>
>>
>>
>>     --
>>     Thomas Eckart
>>     Natural Language Processing Group
>>     Department of Computer Science
>>     University of Leipzig
>>     Augustusplatz 10
>>     04109 Leipzig, Germany
>>
>>
>>
> --
> Thomas Eckart
> Natural Language Processing Group
> Department of Computer Science
> University of Leipzig
> Augustusplatz 10
> 04109 Leipzig, Germany
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clarin.eu/pipermail/tf-curation/attachments/20160701/5927ae66/attachment.html>


More information about the Tf-curation mailing list