Hi Manu,
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?
It's again important to clarify that that is not the case. You can use
any RDFa vocabulary and build a SearchMonkey application that acts on
data formatted according to that vocabulary.
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.
I'm not sure I follow you on this distinction... what do you mean by RSS
is 'fairly strongly typed' data while RDFa is not? RDFa has explicit
typing, just like XML Schema.
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.
I'm not sure I understand what you are referring to. In this case width
and height are attributes in XML, and properties in RDF.
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> ..
This would be incompatible with RDFa, no?
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/
No one has ever requested it until now ;) Why is it better than a
separate OWL document? OWL is very 2009 ;)
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.
I'm not sure if the world is ready for that...
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
Yes...
Hope to keep working through the issues and providing feedback. Thanks
for replying and reading through this rather long set of thoughts :)
-- manu
I'm happy to respond. We should probably try to avoid using this mailing
list for discussions about specific vocabularies. In particular, based
on evidence all over the Web, discussions are media vocabularies tend to
be lengthy and most likely uninteresting for anyone on this list who is
not working with media content.
Best,
Peter
