Hi Manu,

So, if Metacafe were to use this as their markup:

<div xmlns:dcterms="http://purl.org/dc/terms/";
     xmlns:media="http://purl.org/media#";
     xmlns:video="http://purl.org/media/video#";
     about="#cute-puppy" typeof="video:Recording">

<img rev="media:depiction"
   src="http://s.mcstatic.com/thumb/767922.jpg"; />
<span property="dcterms:title">OMG Cute Puppies!</span>
<object rel="media:download"
   href="http://www.metacafe.com/fplayer/767922/cute_puppy.swf"; />
</div>

and you did a search like this:

http://search.yahoo.com/search?p=site%3Ametacafe.com+cute+puppies

Would you get the extended video search listing, or just regular search
listing?
That would be a regular search listing: this needs support on our side given the near impossibility of automated ontology mapping. However, as I said before, we promise to support any media format (RDFa or otherwise) that attracts enough usage. Right now the only external format that meets that criteria is Facebook Share.

I would hope that, in time, one would get an extended video search
listing using a variety of popular video vocabularies.
Yes, that is already the case: we currently support the SearchMonkey media vocabulary (MediaRSS) in RDFa plus Facebook Share. In addition, we also support typed-links simply because it's pure HTML:

<a href="http://example.com/mp3/song"; class="htrack" tabindex="1" title="Movin' Right Along" type="audio/mpeg">my favorite song</a>

This is enough for us to know that this is a music file that can be played by an MP3 player and has a given title, see http://yahoomediaplayer.wikia.com/wiki/How_To_Link

There are two parts to this issue:

1. Lack of typing in Yahoo's Media RDF vocabulary.
2. The implications of not specifying typing and ranges in RDF
   vocabularies.
Your comments here are again highly appreciated and we will take them into account in the next revision of the vocabulary. Small note: the RDF-MT contains a strong warning against the usage of xsd:duration:

The other built-in XML Schema datatypes are unsuitable for various reasons, and *SHOULD NOT* be used: |xsd:duration| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#duration> does not have a well-defined value space (this may be corrected in later revisions of XML Schema datatypes, in which case the revised datatype would be suitable for use in RDF datatyping); |xsd:QName| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#QName> and |xsd:ENTITY| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#ENTITY> require an enclosing XML document context; |xsd:ID| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#ID> and |xsd:IDREF| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#IDREF> are for cross references within an XML document; |xsd:NOTATION| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#NOTATION> is not intended for direct use; |xsd:IDREFS| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#IDREFS>, |xsd:ENTITIES| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#ENTITIES> and |xsd:NMTOKENS| <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#NMTOKENS> are sequence-valued datatypes which do not fit the RDF datatype <http://www.w3.org/TR/rdf-mt/#defDatatype> model. So personally I'm hesitant... it also seems easier to express duration in seconds then in the rather strange value space of xsd:duration.

Here are some elements and attributes of Media RSS that didn't make it
into Yahoo's Media vocab:

mediarss:rating
mediarss:credit    - @role
mediarss:restriction
mediarss:thumbnail - @time
mediarss:content   - @expression, @isDefault
mediarss:text      - @start, @end

So, Yahoo's Media vocabulary wasn't necessarily a direct port of MediaRSS?
I don't know personally the original reasons why these were left out. But it seems they are well covered by other vocabularies: reviews in RDF Review, rights in Dublin Core etc.

<html profile="http://search.yahoo.com/searchmonkey-vocabs.html";>
... <span property="dc:title">Puppies</span> ...
  ... <span property="format:width" content="1080">HD</span> ..
This would be incompatible with RDFa, no?

Right now, yes. In the future, maybe not.

So this is a discussion we should return to in the future ;)
It's better than a separate OWL document because it is both human and
machine-readable. OWL documents are machine-readable and
developer-readable. By keeping your OWL document separated from you
Yahoo developer documentation, you risk the chance of them getting out
of sync.
I wrote the code to generate the documentation directly from the OWL files so they don't get out of sync ;)
Your OWL document is not reference-able by a computer, either. So, if I
wanted to write a validator for Yahoo's Media vocabulary, I can't just
use the same URL that I define in xmlns:ymedia. In other words, the
document at the Yahoo namespace URL:

http://search.yahoo.com/searchmonkey/media

is not machine readable. As an aside, there should really be a '#' at
the end of that URL, otherwise this:

media:Article

will be expanded to this:

http://search.yahoo.com/searchmonkey/mediaArticle

which is not dereference-able.
The examples show the correct namespace declaration:

xmlns:media="http://search.yahoo.com/searchmonkey/media/";

It is possible that some of the documentation is lagging behind ;)


What do you mean? Why does the world need to be ready for this? If we're
done with a vocabulary and there is a better way forward, we'd start
using the new vocabulary, wouldn't we? Why shouldn't we just use a new
URL for that new vocabulary?

Backward compatibility: FOAF is still using the same URIs it started with even though the interpretations of concepts have changed over time.
That, or this discussion just drove 100+ list members away from RDFa :)
Nah... at least people on this list appreciate the full complexity of the issues involved ;) The rest of the world will continue copy-pasting examples from the documentation.

Cheers,
Peter

Reply via email to