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