Ivan, thanks for starting this discussion. Dan Brickley & Danny Ayers from the SemWeb community helped us with this at the time.
would it be possible for you to post this on the SemWeb list, I believe I've seen more recent posts by them there & they pay more attention to that? it would be nice for people there to be reminded about metalink :) (been a few years) & they can probably address your concerns there better. please keep us posted tho, & we'll update any files necessary/add info to the site. On Tue, Sep 28, 2010 at 12:55 PM, Ivan Shmakov <[email protected]> wrote: >>>>>> Anthony Bryan <anthonybr...@…> writes: > > […] > > >> This way, some Metalink documents may be read as RDF/XML documents, > >> provided that the following two superficial changes are made: > > >> • the top-level ‘metalink’ element be replaced with ‘rdf:RDF’; > > >> • all the attributes are given namespace prefixes. > > […] > > >> Unfortunately, most of the valuable elements of Metalink are > >> specified as both having attributes, and being direct descendants of > >> the ‘file’ element, which makes them incompatible with RDF/XML. In > >> particular, these are: ‘metalink:pieces’, ‘metalink:hash’, > >> ‘metalink:metaurl’, ‘metalink:origin’, ‘metalink:publisher’, > >> ‘metalink:signature’, ‘metalink:url’. > > >> While this particular issue could be solved by providing a separate > >> Metalink XML parser to the RDF tool in question (or by providing an > >> XSLT transformation), it isn't clear as to whether the elements > >> above should name (typed) RDF nodes or arcs (or both?) > > > see also > > > http://groups.google.com/group/metalink-discussion/browse_thread/thread/566c588f85ed5b32/9d427439d57a3d4d > > > (note: this covered metalink 3, not the current version/RFC) > > Thanks for the pointer! > > So, I see that that variant solves the issues above as follows. > (There, I imagine that the changes suggested are for the current > version of the Metalink XML specification.) > > The top-level ‘metalink’ element is replaced with ‘Metalink’ > (i. e., as per the common convention, a type; thus, the element > represents a typed node.) Note that an ‘rdf:RDF’ element is > also present, while it's actually optional in this case (as per > 2.6 of the RDF/XML specification.) > > All the attributes are namespace-prefixed. > > The ‘file’ element (under ‘metalink’) is replaced with a ‘file’ > arc leading to a ‘File’ typed node. The ‘pieces’ element is > treated in a similar way. > > The ‘url’ element's destination is specified with > ‘rdf:resource’, so this element designates an RDF graph arc, > leading to a note, describing the resource the URI names. That > way, the ‘location’ and ‘preference’ arcs are associated with > that resource (irrespective of the ‘File’ in question), which > is, to my mind, slightly inappropriate. > > The ‘hash’ element is replaced with a stack of arcs, namely: > ‘md5_hash’, ‘sha1_hash’, ‘ed2k_hash’, ‘sha1’. While the last > one leads to a blank node, containing an ‘rdf:value’ with the > ‘hexBinary’ representation of the hash, all the other ones lead > to the value directly. > > Note that, thanks to this approach, the namespace for possible > hash algorithms is effectively the namespace of URI's. It may > not be the most concise expression, but it for sure gives a room > for extensions. That being said, I'd rather like a single URI > (Qname) per algorithm. > > -- > FSF associate member #7257 > -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads -- 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.
