<br><br><div class="gmail_quote">On Sat, Mar 7, 2009 at 10:29 PM, Peter Flynn <span dir="ltr"><<a href="mailto:peter@silmaril.ie">peter@silmaril.ie</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">Karl Berry wrote:<br>
> Hi Kittipat,<br>
><br>
> You wrote:<br>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'd like to participate in GSoC as a student. I saw the Dublin Core<br>
idea on the GSoC idea list page and I'm quite interested. However,<br>
there's a point in the key deliverables that I couldn't<br>
understand. Specifically, what is the important of "methods for<br>
package authors to declare new metadata element sets and<br>
vocabularies"? It should be no problem if "an implementation of the<br>
Dublin Core Abstract Model in TeX" has already been done, isn'tit?<br>
</blockquote></blockquote>
<br></div></div>
As I understand this, it hinges on the word "new". Kittipat is quite right, if the DCAM is implemented in [La]TeX, then using it isn't the problem. It's when a new element set or vocabulary comes along that we need the ability to adapt to it without reinventing the wheel. The huge increase in usage of Z39.88 because of Zotero is one example.<br>
<br>
There are lots of abstract models for metadata, from the relatively simple bibliographic level (eg BIBTeX) up to the humungously complex one in TEI (implemented for standalone metadata in EAD). I think the point is meant to be, we should be able to adapt as the demand and the usage changes, without having to rewrite everything.<br>
<br>
I'm just back from the IUISC (<a href="http://www.iuisc.ie" target="_blank">www.iuisc.ie</a>) and one of the perennial hot topics was the reuse of metadata. But with 100 librarians in a room, and you ask what model you should use, you get >100 answers :-)<br>
<br>
YMMV<br><font color="#888888">
<br>
///Peter<br>
</font></blockquote></div>Then, implementing RDF should provide more generic solution. There should be one set of instructions for declaring namespaces, resources, properties, statements, etc. These instructions should store the data into token lists for later processing. Another set of instructions would read the data and then export them into target format. This should provide a fairly generic framework for metadata defining and exporting. Then, adding support to any metadata model that can be expressed in RDF is just the matter of declaring the elements. On top of that, a less verbose interface can be defined for end-users uses.<br>
<br>For example, steps in defining DC terms would look like:<br>\rdfnamespace{dcterms:}{<a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a>}<br>\rdfproperties{dctitle}{dcterms:title} %The first argument is an alais for using in declaring statements<br>
...<br>Defining statement would like:<br>\rdfstatement{<a href="http://www.example.com/document}{dctitle}{Example">http://www.example.com/document}{dctitle}{Example</a>}<br>And ther could be shortcuts for end-user like:<br>
\dctitle{Example}<br>or probably more generic:<br>\metatitle{Example}<br>which would map to the term defined in vocabulary set.<br><br>Introducing Z39.88 into the system is, in fact, adding more statements. However, to make it more convenient to end-user, the commands like \metatitle have to be modified in order to automatically generate Z39.88 metadata. The ability to mapping one metadata statement to multiple metadata models is, of course, subject to the compatibility of term definitions.<br>
<br>The limitation of this approach is that the metadata model must be able to be encoded in RDF. The more generic solution would be implementing XML library at the base level but I think that would be too complicated.<br>
<br>Kittipat<br>