Re: Yahoo's RDF vocabularies

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

Received on Tuesday, 24 March 2009 17:25:41 UTC