Anthony Bryan wrote: > On Thu, Aug 20, 2009 at 2:23 AM, Nicolas > Alvarez<[email protected]> wrote: > >> Anthony Bryan wrote: >> >>> maybe metalink in RDF would be a good place to start, I know it uses some >>> DC >>> >>> http://www.metalinker.org/metalink2rdfxml.xsl >>> >> This would be way too big a change. RDF is a totally different data model >> (labeled directed graph) from XML (tree with multiple node types). It just >> happens that it can be represented in a specific XML format. But also in >> other formats, so metalink clients would have to understand more than XML. >> > > I'm not saying use RDF... > > this was in reply to Nils' last 2 questions: > > * Should there be a lot of DC elements that generators should use (as > opposed to other elements). How would we map the current set of > elements to DC elements? > * Can all of the current elements be easily mapped? Which elements > must stay? > > doesn't this xsl file translate Metalink elements into DC? > > <origin> -> <dc:source> > <published> -> <dc:date> > <description> -> <dc:description> > <updated> -> <dcterms:modified> > > anyways, I've been advised against using DC by IETF folk so it's > probably not worth pursuing. :) > Then it's probably not a good idea. In fact I think the best solution might be to select a few meta data fields that we feel are important and work well with the metalink format, and then incorporate those into the standard (like now). The more clients that support all (or most) of the fields the better, IMHO. Having too many meta data fields could lead to a situation where any given field was supported by only a few applications. In that case most of the meta data you entered into a metalink wouldn't ever be used and that isn't good.
I think we should either select a few really useful meta data fields, include only those and then try to get support for them in as many applications as possible. We could also add more fields (possibly by reference) and then recommend every client to support at least a specified subset of them (would work well too, I guess). I doubt many fields would be useful, though. A few applications could probably make use of them, but almost no metalinks will contain such data anyway so then it would still be better to have few and good fields that most metalinks and most applications use. For special applications that use special metalinks (made by the same people), you can always make a special extension. What about selecting a couple of the dublin core (or other) elements and incorporate those into the metalink standard, similar to now? Which would be most useful? Do we really need more than 4 - 5 meta data elements? DC looks quite good, by the way. By including the elements directly in our standard we get the chance to explain them in a metalink context, though. That might be nice. Perhaps more liked by the IETF people too. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
