>>>>> 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
pgp8SKO8PV9uD.pgp
Description: PGP signature
