Hello! (Waking up after a long, long lurking on this list - so hello everyone! and congratulations for the great job you've done!! :) )
> Position can be: > > 1. The position of the track on a CD. > 2. Podcast # of the recording. > 3. The position on a top-10 list. > 4. The physical position on a CD set of an Operatic piece. > 5. The side and track # of an LP (ie: A1, B2) > 6. Specified in TABLE elements. > 7. Can be specified out-of-sequence. > > I don't think we avoided the problem when putting position in there... > it takes on the challenges of positional identifiers for audio > recordings. If we take position out of the hAudio spec, we lose support > for all of the use cases listed above. I agree the POSITION descriptor provides a loose descriptor for such information, and will be ok for a good number of use cases. However, I think that Michael was more referring to was how several "parts" relate to each other - eg. how could we relate the third act 3 of "La Boheme" (the work) and two performances of this act (which may not have the same POSITION, within their whole - the performance). > > If you want further proof, look at the examples... or I can give > examples of pages to prove my point. (I say that somewhat sarcastically, > because you can almost always find examples online to prove a point in > Microformats). > > > For an idea of > > the complexity I'd point semweb minded people at the fine work of Yves > > Raimond on the music ontology (which incidentally it would be nice to see > > used in the rdf-a hAudio spec): > > > > http://musicontology.com/ > > There will probably be multiple OWL mappings from hAudio RDF to > MusicOntology RDF... for example: > > <owl:Class rdf:ID="Recording"> > <owl:equivalentClass > rdf:resource="http://purl.org/ontology/mo/Recording"/> > </owl:Class> > > I've been thinking about heavy re-use of MusicOntology (which is great, > if you need to do more than just markup albums/tracks). The big mistake > I think the MO folks made was putting properties in there that should > have been just plain URIs: > > http://musicontology.com/#term_myspace > http://musicontology.com/#term_amazon_asin > http://musicontology.com/#term_musicmoz > > It's so incredibly heavyweight that it makes most people's heads spin > when attempting to just simply mark up a song. That being said, there > will still be mappings from one to the other (or re-use of some of the > MO vocabulary in the hAudio RDF. Hmm - I don't really get this point... These properties are similar in spirit than the foaf:homepage one (they actually subsume it), and are here to link an URI identifying an artist to a web document one (hence the foaf:Document range). So from the URI of an artist, you can relate to different web documents in different places about him (try the Musicbrainz dataset for examples of this one). Although I do agree that if this document was GRDDL-able, we could use a owl:sameAs relationship here, or directly reuse the URI. Cheers! y _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
