[whatwg] Please review use cases relating to embedding micro-data in text/html

The contacts section uses "event" where it meant contact

On 4/23/09, Ian Hickson <ian at hixie.ch> wrote:
>
> [bcc'ed previous participants in this discussion]
>
> Earlier this year I asked for use cases that HTML5 did not yet cover, with
> an emphasis on use cases relating to semantic microdata. I list below the
> use cases and requirements that I derived from the response to that
> request, and from related discussions.
>
> I would appreciate it if people could review this list for errors or
> important omissions, before I go through the list to work out whether
> these use cases already have solutions, or whether we should have
> solutions for these use cases in HTML, or whether we should address these
> use cases with other technologies, or whatnot.
>
> I encourage people to focus on the use cases themselves, rather than on
> potential solutions; various solutions to all these use cases have already
> been argued in great detail and I have already read all those e-mails,
> blog comments, wiki faqs, etc, carefully.
>
> My primary concern right now is in making sure that these are indeed the
> use cases people care about, so that whatever we add to the spec can be
> carefully evaluated to make sure it is in fact solving the problems that
> we want solving.
>
> ==============================================================================
>
> Exposing known data types in a reusable way
>
>    USE CASE: Exposing calendar events so that users can add those events to
>    their calendaring systems.
>
>    SCENARIOS:
>
>      * A user visits the Avenue Q site and wants to make a note of when
>        tickets go on sale for the tour's stop in his home town. The site
> says
>        "October 3rd", so the user clicks this and selects "add to calendar",
>        which causes an entry to be added to his calendar.
>      * A student is making a timeline of important events in Apple's
> history.
>        As he reads Wikipedia entries on the topic, he clicks on dates and
>        selects "add to timeline", which causes an entry to be added to his
>        timeline.
>      * TV guide listings - browsers should be able to expose to the user's
>        tools (e.g. calendar, DVR, TV tuner) the times that a TV show is on.
>      * Paul sometimes gives talks on various topics, and announces them on
>        his blog. He would like to mark up these announcements with proper
>        scheduling information, so that his readers' software can
>        automatically obtain the scheduling information and add it to their
>        calendar. Importantly, some of the rendered data might be more
>        informal than the machine-readable data required to produce a
> calendar
>        event. Also of importance: Paul may want to annotate his event with a
>        combination of existing vocabularies and a new vocabulary of his own
>        design. (why?)
>      * David can use the data in a web page to generate a custom browser UI
>        for adding an event to our calendaring software without using brittle
>        screen-scraping.
>
>    REQUIREMENTS:
>
>      * Should be discoverable.
>      * Should be compatible with existing calendar systems.
>      * Should be unlikely to get out of sync with prose on the page.
>      * Shouldn't require the consumer to write XSLT or server-side code to
>        read the calendar information.
>      * Machine-readable event data shouldn't be on a separate page than
>        human-readable dates.
>      * The information should be convertible into a dedicated form (RDF,
>        JSON, XML, iCalendar) in a consistent manner, so that tools that use
>        this information separate from the pages on which it is found have a
>        standard way of conveying the information.
>      * Should be possible for different parts of an event to be given in
>        different parts of the page. For example, a page with calendar events
>        in columns (with each row giving the time, date, place, etc) should
>        still have unambiguous calendar events parseable from it.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Exposing contact details so that users can add people to their
>    address books or social networking sites.
>
>    SCENARIOS:
>
>      * Instead of giving a colleague a business card, someone gives their
>        colleague a URL, and that colleague's user agent extracts basic
>        profile information such as the person's name along with references
> to
>        other people that person knows and adds the information into an
>        address book.
>      * A scholar and teacher wants other scholars (and potentially students)
>        to be able to easily extract information about who he is to add it to
>        their contact databases.
>      * Fred copies the names of one of his Facebook friends and pastes it
>        into his OS address book; the contact information is imported
>        automatically.
>      * Fred copies the names of one of his Facebook friends and pastes it
>        into his Webmail's address book feature; the contact information is
>        imported automatically.
>      * David can use the data in a web page to generate a custom browser UI
>        for including a person in our address book without using brittle
>        screen-scraping.
>
>    REQUIREMENTS:
>
>      * A user joining a new social network should be able to identify
> himself
>        to the new social network in way that enables the new social network
>        to bootstrap his account from existing published data (e.g. from
>        another social nework) rather than having to re-enter it, without the
>        new site having to coordinate (or know about) the pre-existing site,
>        without the user having to give either sites credentials to the
> other,
>        and without the new site finding out about relationships that the
> user
>        has intentionally kept secret.
>        (http://w2spconf.com/2008/papers/s3p2.pdf)
>      * Data should not need to be duplicated between machine-readable and
>        human-readable forms (i.e. the human-readable form should be
>        machine-readable).
>      * Shouldn't require the consumer to write XSLT or server-side code to
>        read the contact information.
>      * Machine-readable contact information shouldn't be on a separate page
>        than human-readable contact information.
>      * The information should be convertible into a dedicated form (RDF,
>        JSON, XML, vCard) in a consistent manner, so that tools that use this
>        information separate from the pages on which it is found have a
>        standard way of conveying the information.
>      * Should be possible for different parts of an event to be given in
>        different parts of the page. For example, a page with contact details
>        for people in columns (with each row giving the name, telephone
>        number, etc) should still have unambiguous grouped contact details
>        parseable from it.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Allow users to maintain bibliographies or otherwise keep track
>    of sources of quotes or references.
>
>    SCENARIOS:
>
>      * Frank copies a sentence from Wikipedia and pastes it in some word
>        processor: it would be great if the word processor offered to
>        automatically create a bibliographic entry.
>      * Patrick keeps a list of his scientific publications on his web site.
>        He would like to provide structure within this publications page so
>        that Frank can automatically extract this information and use it to
>        cite Patrick's papers without having to transcribe the bibliographic
>        information.
>      * A scholar and teacher wants other scholars (and potentially students)
>        to be able to easily extract information about what he has published
>        to add it to their bibliographic applications.
>      * A scholar and teacher wants to publish scholarly documents or content
>        that includes extensive citations that readers can then automatically
>        extract so that they can find them in their local university library.
>        These citations may be for a wide range of different sources: an
>        interview posted on YouTube, a legal opinion posted on the Supreme
>        Court web site, a press release from the White House.
>      * A blog, say htmlfive.net, copies content wholesale from another, say
>        blog.whatwg.org (as permitted and encouraged by the license). The
>        author of the original content would like the reader of the
> reproduced
>        content to know the provenance of the content. The reader would like
>        to find the original blog post so he can leave comments for the
>        original author.
>      * Chaals could improve the Opera intranet if he had a mechanism for
>        identifying the original source of various parts of a page. (why?)
>
>    REQUIREMENTS:
>
>      * Machine-readable bibliographic information shouldn't be on a separate
>        page than human-readable bibliographic information.
>      * The information should be convertible into a dedicated form (RDF,
>        JSON, XML, BibTex) in a consistent manner, so that tools that use
> this
>        information separate from the pages on which it is found have a
>        standard way of conveying the information.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Help people searching for content to find content covered by
>    licenses that suit their needs.
>
>    SCENARIOS:
>
>      * If a user is looking for recipes of pies to reproduce on his blog, he
>        might want to exclude from his results any recipes that are not
>        available under a license allowing non-commercial reproduction.
>      * Lucy wants to publish her papers online. She includes an abstract of
>        each one in a page, but because they are under different copyright
>        rules, she needs to clarify what the rules are. A harvester such as
>        the Open Access project can actually collect and index some of them
>        with no problem, but may not be allowed to index others. Meanwhile, a
>        human finds it more useful to see the abstracts on a page than have
> to
>        guess from a bunch of titles whether to look at each abstract.
>      * There are mapping organisations and data producers and people who
> take
>        photos, and each may place different policies. Being able to keep
> that
>        policy information helps people with further mashups avoiding
>        violating a policy. For example, if GreatMaps.com has a public domain
>        policy on their maps, CoolFotos.org has a policy that you can use
> data
>        other than images for non-commercial purposes, and Johan Ichikawa has
>        a photo there of my brother's cafe, which he has licensed as "must
> pay
>        money", then it would be reasonable for me to copy the map and put it
>        in a brochure for the cafe, but not to copy the data and photo from
>        CoolFotos. On the other hand, if I am producing a non-commercial
> guide
>        to cafes in Melbourne, I can add the map and the location of the cafe
>        photo, but not the photo itself.
>      * At University of Mary Washington, many faculty encourage students to
>        blog about their studies to encourage more discussion using an
>        instance of WordPress MultiUser. A student with have a blog might be
>        writing posts relevant to more than one class. Professors would like
>        to then aggregate relevant posts into one blog.
>      * Tara runs a video sharing web site for people who want licensing
>        information to be included with their videos. When Paul wants to blog
>        about a video, he can paste a fragment of HTML provided by Tara
>        directly into his blog. The video is then available inline in his
>        blog, along with any licensing information about the video.
>      * Fred's browser can tell him what license a particular video on a site
>        he is reading has been released under, and advise him on what the
>        associated permissions and restrictions are (can he redistribute this
>        work for commercial purposes, can he distribute a modified version of
>        this work, how should he assign credit to the original author, what
>        jurisdiction the license assumes, whether the license allows the work
>        to be embedded into a work that uses content under various other
>        licenses, etc).
>
>    REQUIREMENTS:
>
>      * Content on a page might be covered by a different license than other
>        content on the same page.
>      * When licensing a subpart of the page, existing implementations must
>        not just assume that the license applies to the whole page rather
> than
>        just part of it.
>      * License proliferation should be discouraged.
>      * License information should be able to survive from one site to
> another
>        as the data is transfered.
>      * Expressing copyright licensing terms should be easy for content
>        creators, publishers, and redistributors to provide.
>      * It should be more convenient for the users (and tools) to find and
>        evaluate copyright statements and licenses than it is today.
>      * Shouldn't require the consumer to write XSLT or server-side code to
>        process the license information.
>      * Machine-readable licensing information shouldn't be on a separate
> page
>        than human-readable licensing information.
>      * There should not be ambiguous legal implications.
>
> ==============================================================================
>
> Annotations
>
>    USE CASE: Annotate structured data that HTML has no semantics for, and
>    which nobody has annotated before, and may never again, for private use
> or
>    use in a small self-contained community.
>
>    SCENARIOS:
>
>      * A group of users want to mark up their iguana collections so that
> they
>        can write a script that collates all their collections and presents
>        them in a uniform fashion.
>      * A scholar and teacher wants other scholars (and potentially students)
>        to be able to easily extract information about what he teaches to add
>        it to their custom applications.
>      * The list of specifications produced by W3C, for example, and various
>        lists of translations, are produced by scraping source pages and
>        outputting the result. This is brittle. It would be easier if the
> data
>        was unambiguously obtainable from the source pages. This is a custom
>        set of properties, specific to this community.
>      * Chaals wants to make a list of the people who have translated W3C
>        specifications or other documents, and then use this to search for
>        people who are familiar with a given technology at least at some
>        level, and happen to speak one or more languages of interest.
>      * Chaals wants to have a reputation manager that can determine which of
>        the many emails sent to the WHATWG list might be "more than usually
>        valuable", and would like to seed this reputation manager from
>        information gathered from the same source as the scraper that
>        generates the W3C's TR/ page.
>      * A user wants to write a script that finds the price of a book from an
>        Amazon page.
>      * Todd sells an HTML-based content management system, where all
>        documents are processed and edited as HTML, sent from one editor to
>        another, and eventually published and indexed. He would like to build
>        up the editorial metadata used by the system within the HTML
> documents
>        themselves, so that it is easier to manage and less likely to be
> lost.
>      * Tim wants to make a knowledge base seeded from statements made in
>        Spanish and English, e.g. from people writing down their thoughts
>        about George W. Bush and George H.W. Bush, and has either convinced
>        the people making the statements that they should use a common
>        language-neutral machine-readable vocabulary to describe their
>        thoughts, or has convinced some other people to come in after them
> and
>        process the thoughts manually to get them into a computer-readable
>        form.
>
>    REQUIREMENTS:
>
>      * Vocabularies can be developed in a manner that won't clash with
> future
>        more widely-used vocabularies, so that those future vocabularies can
>        later be used in a page making use of private vocabularies without
>        making the earlier annotations ambiguous.
>      * Using the data should not involve learning a plethora of new APIs,
>        formats, or vocabularies (today it is possible, e.g., to get the
> price
>        of an Amazon product, but it requires learning a new API; similarly
>        it's possible to get information from sites consistently using
> 'class'
>        values in a documented way, but doing so requires learning a new
>        vocabulary).
>      * Shouldn't require the consumer to write XSLT or server-side code to
>        process the annotated data.
>      * Machine-readable annotations shouldn't be on a separate page than
>        human-readable annotations.
>      * The information should be convertible into a dedicated form (RDF,
>        JSON, XML) in a consistent manner, so that tools that use this
>        information separate from the pages on which it is found have a
>        standard way of conveying the information.
>      * Should be possible for different parts of an item's data to be given
>        in different parts of the page, for example two items described in
> the
>        same paragraph. ("The two lamps and A and B. The first is $20, the
>        second $30. The first is 5W, the second 7W.")
>      * It should be possible to define globally-unique names, but the syntax
>        should be optimised for a set of predefined vocabularies.
>      * Adding this data to a page should be easy.
>      * The syntax for adding this data should encourage the data to remain
>        accurate when the page is changed.
>      * The syntax should be resilient to intentional copy-and-paste
>        authoring: people copying data into the page from a page that already
>        has data should not have to know about any declarations far from the
>        data.
>      * The syntax should be resilient to unintentional copy-and-paste
>        authoring: people copying markup from the page who do not know about
>        these features should not inadvertently mark up their page with
>        inapplicable data.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Allow authors to annotate their documents to highlight the key
>    parts, e.g. as when a student highlights parts of a printed page, but in
> a
>    hypertext-aware fashion.
>
>    SCENARIOS:
>
>      * Fred writes a page about Napoleon. He can highlight the word Napoleon
>        in a way that indicates to the reader that that is a person. Fred can
>        also annotate the page to indicate that Napoleon and France are
>        related concepts.
>
> ==============================================================================
>
> Search
>
>    USE CASE: Site owners want a way to provide enhanced search results to
> the
>    engines, so that an entry in the search results page is more than just a
>    bare link and snippet of text, and provides additional resources for
> users
>    straight on the search page without them having to click into the page
> and
>    discover those resources themselves.
>
>    SCENARIOS:
>
>      * For example, in response to a query for a restaurant, a search engine
>        might want to have the result from yelp.com provide additional
>        information, e.g. info on price, rating, and phone number, along with
>        links to reviews or photos of the restaurant.
>
>    REQUIREMENTS:
>
>      * Information for the search engine should be on the same page as
>        information that would be shown to the user if the user visited the
>        page.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Search engines and other site categorisation and aggregation
>    engines should be able to determine the contents of pages with more
>    accuracy than today.
>
>    SCENARIOS
>
>      * Students and teachers should be able to discover each other -- both
>        within an institution and across institutions -- via their blogging.
>      * A blogger wishes to categorise his posts such that he can see them in
>        the context of other posts on the same topic, including posts by
>        unrelated authors (i.e. not via a pre-agreed tag or identifier, not
>        via a single dedicated and preconfigured aggregator).
>      * A user whose grandfather is called "Napoleon" wishes to ask Google
> the
>        question "Who is Napoleon", and get as his answer a page describing
>        his grandfather.
>      * A user wants to ask about "Napoleon" but, instead of getting an
>        answer, wants the search engine to ask him which Napoleon he wants to
>        know about.
>
>    REQUIREMENTS:
>
>      * Should not disadvantage pages that are more useful to the user but
>        that have not made any effort to help the search engine.
>      * Should not be more susceptible to spamming than today's markup.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Web browsers should be able to help users find information
>    related to the items discussed by the page that they are looking at.
>
>    SCENARIOS:
>
>      * Finding more information about a movie when looking at a page about
>        the movie, when the page contains detailed data about the movie.
>           * For example, where the movie is playing locally.
>           * For example, what your friends thought of it.
>      * Exposing music samples on a page so that a user can listen to all the
>        samples.
>      * Students and teachers should be able to discover each other -- both
>        within an institution and across institutions -- via their blogging.
>      * David can use the data in a web page to generate a custom browser UI
>        for calling a phone number using our cellphone without using brittle
>        screen-scraping.
>
>    REQUIREMENTS:
>
>      * Should be discoverable, because otherwise users will not use it, and
>        thus users won't be helped.
>      * Should be consistently available, because if it only works on some
>        pages, users will not use it (see, for instance, the rel=next story).
>      * Should be bootstrapable (rel=next failed because UAs didn't expose it
>        because authors didn't use it because UAs didn't expose it).
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Finding distributed comments on audio and video media.
>
>    SCENARIOS:
>
>      * Sam has posted a video tutorial on how to grow tomatoes on his video
>        blog. Jane uses the tutorial and would like to leave feedback to
>        others that view the video regarding certain parts of the video she
>        found most helpful. Since Sam has comments disabled on his blog, his
>        users cannot comment on the particular sections of the video other
>        than linking to it from their blog and entering the information
> there.
>        Jane uses a video player that aggregates all the comments about the
>        video found on the Web, and displays them as subtitles while she
>        watches the video.
>
>    REQUIREMENTS:
>
>      * It shouldn't be possible for Jane to be exposed to spam comments.
>      * The comment-aggregating video player shouldn't need to crawl the
>        entire Web for each user independently.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Allow users to price-check digital media (music, TV shows, etc)
>    and purchase such content without having to go through a special website
>    or application to acquire it, and without particular retailers being
>    selected by the content's producer or publisher.
>
>    SCENARIOS:
>
>      * Joe wants to sell his music, but he doesn't want to sell it through a
>        specific retailer, he wants to allow the user to pick a retailer. So
>        he forgoes the chance of an affiliate fee, negotiates to have his
>        music available in all retail stores that his users might prefer, and
>        then puts a generic link on his page that identifies the product but
>        doesn't identifier a retailer. Kyle, a fan, visits his page, clicks
>        the link, and Amazon charges his credit card and puts the music into
>        his Amazon album downloader. Leo instead clicks on the link and is
>        automatically charged by Apple, and finds later that the music is in
>        his iTunes library.
>      * Manu wants to go to Joe's website but check the price of the offered
>        music against the various retailers that sell it, without going to
>        those retailers' sites, so that he can pick the cheapest retailer.
>      * David can use the data in a web page to generate a custom browser UI
>        for buying a song from our favorite online music store without using
>        brittle screen-scraping.
>
>    REQUIREMENTS:
>
>      * Should not be easily prone to clickjacking (sites shouldn't be able
> to
>        charge the user without the user's consent).
>      * Should not make transactions harder when the user hasn't yet picked a
>        favourite retailer.
>
> ==============================================================================
>
> Cross-site communication
>
>    USE CASE: Copy-and-paste should work between Web apps and native apps and
>    between Web apps and other Web apps.
>
>    SCENARIOS:
>
>      * Fred copies an e-mail from Apple Mail into GMail, and the e-mail
>        survives intact, including headers, attachments, and
> multipart/related
>        parts.
>      * Fred copies an e-mail from GMail into Hotmail, and the e-mail
> survives
>        intact, including headers, attachments, and multipart/related parts.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Allow users to share data between sites (e.g. between an online
>    store and a price comparison site).
>
>    SCENARIOS
>
>      * Lucy is looking for a new apartment and some items with which to
>        furnish it. She browses various web pages, including apartment
>        listings, furniture stores, kitchen appliances, etc. Every time she
>        finds an item she likes, she points to it and transfers its details
> to
>        her apartment-hunting page, where her picks can be organized, sorted,
>        and categorized.
>      * Lucy uses a website called TheBigMove.com to organize all aspects of
>        her move, including items that she is tracking for the move. She goes
>        to her "To Do" list and adds some of the items she collected during
>        her visits to various Web sites, so that TheBigMove.com can handle
> the
>        purchasing and delivery for her.
>
>    REQUIREMENTS:
>
>      * Should be discoverable, because otherwise users will not use it, and
>        thus users won't be helped.
>      * Should be consistently available, because if it only works on some
>        pages, users will not use it (see, for instance, the rel=next story).
>      * Should be bootstrapable (rel=next failed because UAs didn't expose it
>        because authors didn't use it because UAs didn't expose it).
>      * The information should be convertible into a dedicated form (RDF,
>        JSON, XML) in a consistent manner, so that tools that use this
>        information separate from the pages on which it is found have a
>        standard way of conveying the information.
>
> ==============================================================================
>
> Blogging
>
>    USE CASE: Remove the need for feeds to restate the content of HTML pages
>    (i.e. replace Atom with HTML).
>
>    SCENARIOS:
>
>      * Paul maintains a blog and wishes to write his blog in such a way that
>        tools can pick up his blog post tags, authors, titles, and his
>        blogroll directly from his blog, so that he does not need to maintain
>        a parallel version of his data in a "structured format." In other
>        words, his HTML blog should be usable as its own structured feed.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Allow users to compare subjects of blog entries when the
>    subjects are hard to tersely identify relative to other subjects in the
>    same general area.
>
>    SCENARIOS:
>
>      * Paul blogs about proteins and genes. His colleagues also blog about
>        proteins and genes. Proteins and genes are identified by long
>        hard-to-compare strings, but Paul and his colleagues can determine if
>        they are talking about the same things by having their user agent
>        compare some sort of flags embedded in the blogs.
>      * Rob wants to publish a large vocabulary in RDFS and/or OWL. Rob also
>        wants to provide a clear, human readable description of the same
>        vocabulary, that mixes the terms with descriptive text in HTML.
>
> ==============================================================================
>
> Data extraction from uncooperative sources
>
>    USE CASE: Getting data out of poorly written Web pages, so that the user
>    can find more information about the page's contents.
>
>    SCENARIOS:
>
>      * Alfred merges data from various sources in a static manner,
> generating
>        a new set of data. Bob later uses this static data in conjunction
> with
>        other data sets to generate yet another set of static data. Julie
> then
>        visits Bob's page later, and wants to know where and when the various
>        sources of data Bob used come from, so that she can evaluate its
>        quality. (In this instance, Alfred and Bob are assumed to be
>        uncooperative, since creating a static mashup would be an example of
> a
>        poorly-written page.)
>      * TV guide listings - If the TV guide provider does not render a link
> to
>        IMDB, the browser should recognise TV shows and give implicit links.
>        (In this instance, it is assumed that the TV guide provider is
>        uncooperative, since it isn't providing the links the user wants.)
>      * Students and teachers should be able to discover each other -- both
>        within an institution and across institutions -- via their blogging.
>        (In this instance, it is assumed that the teachers and students
> aren't
>        cooperative, since they would otherwise be able to find each other by
>        listing their blogs in a common directory.)
>      * Tim wants to make a knowledge base seeded from statements made in
>        Spanish and English, e.g. from people writing down their thoughts
>        about George W. Bush and George H.W. Bush. (In this instance, it is
>        assumed that the people writing the statements aren't cooperative,
>        since if they were they could just add the data straight into the
>        knowledge base.)
>
>    REQUIREMENTS:
>
>      * Does not need cooperation of the author (if the page author was
>        cooperative, the page would be well-written).
>      * Shouldn't require the consumer to write XSLT or server-side code to
>        derive this information from the page.
>
>
> ---------------------------------------------------------------------------
>
>    USE CASE: Remove the need for RDF users to restate information in online
>    encyclopedias (i.e. replace DBpedia).
>
>    SCENARIOS:
>
>      * A user wants to have information in RDF form. The user visits
>        Wikipedia, and his user agent can obtain the information without
>        relying on DBpedia's interpretation of the page.
>
>    REQUIREMENTS:
>
>      * All the data exposed by DBpedia should be derivable from Wikipedia
>        without using DBpedia.
>
> ==============================================================================
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

-- 
Sent from my mobile device

Received on Friday, 24 April 2009 04:35:05 UTC