Re: Yahoo's RDF vocabularies

Peter Mika wrote:
> I would like to start by saying that we are always open for dialog!

That is very good to hear and I do appreciate you following up on this
thread. :)

> I would like to add --simply because it seems to be a common
> misunderstanding-- is that you can use any and all vocabularies in
> conjunction with SearchMonkey, including your own media vocabularies.

Thanks for the clarification, although my point was in reference to this
page:

http://developer.search.yahoo.com/help/objects/video

SearchMonkey outlines what people must do to get their video listings in
Yahoo's search service using the Yahoo Media vocabulary. So while you
can write your own SearchMonkey apps using your own vocabularies, you
can (right now) only use Yahoo's vocabulary if you want the enhanced
search listings to show up on the main Yahoo search page, right? This
sends a pretty strong message - use Yahoo's vocabularies or you won't
show up in the enhanced listings.

What's the timeline for allowing other vocabularies to be used for
indexing purposes for the main search page listings?

> As a way of explanation, you also have to know that when creating the
> initial SearchMonkey documentation, we included vocabularies that we
> felt were stable enough, covered major interests, and were widespread 
> including Dublin Core, FOAF and others. 

This was a very good move, and I commend your team for not re-inventing
the wheel and for re-using pre-existing vocabularies.

> However, we wanted the
> documentation to be complete and provide simple vocabularies in areas
> where none existed or on the contrary, too many existed. The engineer
> who created the media vocabulary followed the best practice of taking an
> existing format (MediaRSS) and translating it into RDF. 

The MediaRSS syndication format does not map cleanly into a rich RDF
vocabulary. Even if it did, the vocabulary should have been called Media
RSS RDF, or used the "mrss:" prefix to be more clear about what is going on.

Taking something that already exists for syndication purposes and
transforming it into an RDF vocabulary on a 1-to-1 basis is not a best
practice because the syndication format makes some very strong
assumptions about the data in the stream. RSS data is fairly strongly
typed data, and is machine generated in a controlled environment. RDFa
data is usually not strongly typed, is generated by humans as well as
machines, and is not in a very controlled environment.

MediaRSS also contains both elements /and/ attributes to refine the
meaning of the elements. However, it seems that only the elements made
it over to ymedia, which is unfortunate because a great deal of semantic
fidelity is lost without the attributes.

Also, the vocabulary specifies both ymedia:title /and/ suggests the use
of dc:title. There is no need for ymedia:title since you're just
re-defining what dc:title already does. There is an argument for helping
web authors by only requiring them to include one vocabulary, but it is
at the expense of teaching people that it's okay to re-create entire
vocabularies under that argument - which is detrimental to all of this
in the long run.

I think the solution would be something along the lines of @profile
pre-loading a set of vocabularies, so Yahoo could use multiple
vocabularies in a stack without creating undue burden on the HTML author:

<html profile="http://search.yahoo.com/searchmonkey-vocabs.html">
... <span property="dc:title">Puppies</span> ...
  ... <span property="format:width" content="1080">HD</span> ..

> We do publish OWL definitions for the vocabularies at [2].

Good! But that's so 2007! :)

Why not mark up the same pages that define the human readable vocabulary
with a machine readable one using RDFa, like these pages do:

http://purl.org/media/
http://purl.org/media/audio
http://purl.org/media/video
http://purl.org/commerce/

> All your suggestions to improve this
> vocabulary or any other are highly welcome. There are only two
> requirements: they have to be specific enough to implement and backwards
> compatible.

Fair enough.

> (As we are painfully aware of, schema versioning is an
> unsolved problem on the Semantic Web.) 

Hmm, maybe... I thought the general sense on the web was that schema
versioning was a bad idea and should not be done. If you really need to
shift versions, you can always point people at a new URL and clearly
mark the old URL as deprecated, as the Dublin Core folks did.

> The only non-issue I see from
> your list of comments is the issue of prefixes: we have URIs in RDF(a)
> and there already plenty of namespace clashes in the sense you describe:
> RDF Calendar and Dublin Core both have at least two namespaces.

Right, which is why I pointed out RDFa's resiliency in the previous
e-mail... but it still does create a rather large problem for these
types of proposals, so I don't think it is a non-issue... just one that
we may be able to begrudgingly live with:

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Mar/0037.html

Hope to keep working through the issues and providing feedback. Thanks
for replying and reading through this rather long set of thoughts :)

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Absorbing Costs Considered Harmful
http://blog.digitalbazaar.com/2009/02/27/absorbing-costs-harmful

Received on Thursday, 19 March 2009 06:53:27 UTC