<div dir="ltr"><div>Hi all,</div><div><br></div><div>great to see this issue being discussed on the EU level, as Thomas said, we've been trying for some time to arrive at some solution for the WebLicht scenario, I suppose the WebLicht team are also on one of the lists and can benefit from the suggestions and the input :)</div><div><br></div><div>I think the standards/IANA aspect might be a valid argument against the solution with individual non-(yet-)approved mime types, but on the other hand I don't really see how an xml or even tei mime type can be information enough for webservices relevant for processing linguistic resources.</div><div><br></div><div>Either way, we really need to agree on a uniform and useful way of describing and listing formats (not only TEI variants) in CLARIN, since most of the relevant formats share a standard mimetype. And maybe here I could just (once more) point to the Format Registry (<a href="https://trac.clarin.eu/wiki/FormatRegistry" target="_blank">https://trac.clarin.eu/wiki/FormatRegistry</a>) - or rather what the format registry should be (or maybe I should ask where something replacing this link is, and I just haven't heard about it). I guess if the declaration of formats being used is done with CMDI, someone could theoretically harvest all of this information and display it, and we'd find out about inconsistencies, but there are of course other ways to achieve this. Has there been any recent development in creating this kind of inventory?</div><div><br></div><div>Thanks and best regards,</div><div>Hanna</div><div><br></div>-- <br><div data-smartmail="gmail_signature">Hanna Hedeland<br>Hamburger Zentrum für Sprachkorpora<br>Max-Brauer-Allee 60<br>D - 22765 Hamburg<br><br>Tel. <a href="tel:%2B%2049%2040%2042838%206893" value="+4940428386893" target="_blank">+ 49 40 42838 6893</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-17 13:00 GMT+02:00 Sander Maijers <span dir="ltr"><<a href="mailto:sander@clarin.eu" target="_blank">sander@clarin.eu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">*not only the proper<br>
BTW, the same holds for suffixes.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Jun 17, 2016 at 12:59 PM, Sander Maijers <<a href="mailto:sander@clarin.eu">sander@clarin.eu</a>> wrote:<br>
> Hi Dieter,<br>
><br>
> Using custom media types can be done in the a number of ways,<br>
> described in <a href="https://en.wikipedia.org/wiki/Media_type#Registration_trees" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Media_type#Registration_trees</a><br>
> .<br>
> You stated the benefits of your solution well. Your solution has the<br>
> following costs:<br>
> - You'll have to either go through IANA registration procedure for new<br>
> media types in the ‘Personal or Vanity’ tree, go through IETF<br>
> Standards Action to get a CLARIN-specific tree, or break the standards<br>
> and use custom media types outside of this process.<br>
> - Whatever you opt in this context, no third-party (i.e., general,<br>
> standards compliant tools) will recognize the media type of centre's<br>
> content retrieved via PID URLs anymore.<br>
><br>
> I find Menzo's approach not the proper as well as most useful one<br>
> compared to media type based approaches. After all, you would want a<br>
> resource's metadata to be completely descriptive of such elementary<br>
> aspects as internal structure and content of the TEI files, and not<br>
> dependent on system configuration (served as custom media type x or y,<br>
> as long as the server remains so configured).<br>
><br>
> Best,<br>
> Sander<br>
><br>
><br>
> On Fri, Jun 17, 2016 at 11:39 AM, Dieter Van Uytvanck <<a href="mailto:dieter@clarin.eu">dieter@clarin.eu</a>> wrote:<br>
>> On 16/06/16 20:35, Thomas Schmidt wrote:<br>
>>> Therefore, we would need to distinguish this at whathever the place is<br>
>>> where WebLicht distinguishes file formats. If it is via the mime type,<br>
>>> we would need a mime type extension like "text/x-tei-isospoken+xml"<br>
>>> vs. "text/x-tei-dta+xml". If it is on some other level, we would have<br>
>>> to know which and agree on a suitable set of TEI variant identifiers.<br>
>>> I'm copying relevant parts of the mailing list exchange below for your<br>
>>> information.<br>
>><br>
>> Dear Thomas,<br>
>><br>
>> Thank you for this very insightful summary of the discussions on this<br>
>> topic. Looking at all the suggestions made, I think having detailed<br>
>> mimetype extensions would be the most convenient for most parties involved:<br>
>><br>
>> - It puts the responsibility of providing an exact data type for a file<br>
>> at the side of the metadata creator/resource provider. This is always<br>
>> better than relying on interpretation by a third-party tool.<br>
>><br>
>> - It does not require changes to (CMDI) metadata profiles.<br>
>><br>
>> - It makes it feasible for tool/data matching applications (WebLicht,<br>
>> Switchboard, ...) to provide a meaningful processing application.<br>
>><br>
>> There are of course approaches on other levels too (like suggested by<br>
>> Bart and Menzo), and these could be used in addition to the extended TEI<br>
>> mimetypes:<br>
>><br>
>> - Matching applications could still try to parse a TEI file (in absence<br>
>> of a detailed mime type) and make a guess about the sub-type, and using<br>
>> @type where available. This is of course not trivial.<br>
>><br>
>> - The ParameterGroup in the CMDI description can be added. But in many<br>
>> cases that requires metadata providers to change their profiles, which<br>
>> means quite a bit of additional work.<br>
>><br>
>> I will join the TEI weblicht list, and try to gather a bit more concrete<br>
>> information in the upcoming time at<br>
>><br>
>> <a href="https://trac.clarin.eu/wiki/TEI%20variants" rel="noreferrer" target="_blank">https://trac.clarin.eu/wiki/TEI%20variants</a><br>
>><br>
>> (feel free to edit along)<br>
>><br>
>> When we have that additional information, we can try to come up with<br>
>> concrete recommendations.<br>
>><br>
>> best regards,<br>
>> --<br>
>> Dieter Van Uytvanck<br>
>> Technical Director CLARIN ERIC<br>
>> <a href="http://www.clarin.eu" rel="noreferrer" target="_blank">www.clarin.eu</a> | tel. <a href="tel:%2B31-%280%29850091363" value="+31850091363">+31-(0)850091363</a> | skype: dietervu.mpi<br>
>> _______________________________________________<br>
>> Dev mailing list<br>
>> <a href="mailto:Dev@lists.clarin.eu">Dev@lists.clarin.eu</a><br>
>> <a href="https://lists.clarin.eu/cgi-bin/mailman/listinfo/dev" rel="noreferrer" target="_blank">https://lists.clarin.eu/cgi-bin/mailman/listinfo/dev</a><br>
_______________________________________________<br>
Dev mailing list<br>
<a href="mailto:Dev@lists.clarin.eu">Dev@lists.clarin.eu</a><br>
<a href="https://lists.clarin.eu/cgi-bin/mailman/listinfo/dev" rel="noreferrer" target="_blank">https://lists.clarin.eu/cgi-bin/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Hanna Hedeland<br>Hamburger Zentrum für Sprachkorpora<br>Max-Brauer-Allee 60<br>D - 22765 Hamburg<br><br>Tel. + 49 40 42838 6893</div>
</div>