[whatwg] embedding meta data for copy/paste usages - possible use case for RDF-in-HTML?

[Hallvord R M Steen]

>> I'd like some way to add meta data to a page that could be integrated
>> with the UA's copy/paste commands.
>
> These use cases are a good start, but the problem is that you've begun with
> the assumption that copy and paste would be a part of the solution.

That's not a bug, it's a feature :)

Ian said a while ago that coming up with end-user friendly UI ideas
for the RDF stuff was harder than doing the technical work - implying
that if there are no good UI ideas, browser vendors would not find a
nice way to let users use metadata, and many of the use cases for
embedding it in HTML would not really be feasible.

Thus, this *is* a UI proposal, aiming to show that an operation nearly
*all* users are familiar with could be enhanced with richer ways to
embed meta data in HTML.

>> For example, if I copy a sentence from Wikipedia and paste it in some
>> word processor, it would be great if the word processor offered to
>> automatically create a bibliographic entry.
>
> Do you mean a bibliographic entry that references the source web site, and
> included information such as the URL, title, publication date and author
> names?

Exactly.

>  That could be a useful feature, even if it could only obtain the URL
> and title easily.
>
> Often, when writing an article that quotes several websites, it's a time
> consuming process to copy and paste the quote, then the page or article
> title and then the URL to link to it.  An editor with a Paste as Quotation
> feature which helped automate that would be useful.

It would be great. I hate the clumsy back-and-forward switching to
copy/paste all those bits of information ;-p

> HTML5 already contains elements that can be used to help obtain this
> information, such as the <title>, <article> and it's associated heading <h1>
> to <h6> and <time>.  Obtaining author names might be a little more
> difficult, though perhaps hCard might help.

Indeed. And it's not an either-or counter-suggestion to my proposal,
UAs could fall back to extracting such data if more structured meta
data is not available.

>> If I copy the name of one of my Facebook "friends" and paste it into
>> my OS address book, it would be cool if the contact information was
>> imported automatically. Or maybe I pasted it in my webmail's address
>> book feature, and the same import operation happened..
>
> I believe this problem is adequately addressed by the hCard microformat and
> various browser extensions that are available for some browsers, like
> Firefox.  The solution doesn't need to involve a copy and paste operation.
>  It just needs a way to select contact info on the page and export it to an
> address book.

This is way more complicated for most users. Your last sentence IMO is
not an appropriate way to use the word "just", seeing that you need to
find and invoke an "export" command, handle files, find and invoke an
"import" command and clear out the duplicated entries.. This is
impossible for several users I can think of, and even for techies like
us doing so repeatedly will eventually be a chore (even if we CAN, it
doesn't mean that's the way we SHOULD be working).

Besides, it doesn't really address the "copy ONE contact's
information" use case well.

Also, should any program that wants to support copy-and-paste of
contact information have to support text/html parsing and look for
class="" values? I guess that would be quite some work for the rather
limited functionality microformats gives you. It would be better with
a microformat-aware UA generating a common meta data interchange
format for the clipboard, and from there there it seems a small step
to allow web page authors to embed richer meta data the UA can use to
generate the clipboard meta data, right there in their HTML.

>> If I select an E-mail in my webmail and copy it, it would be awesome
>> if my desktop mail client would just import the full E-mail with
>> complete headers and different parts if I just switch to the mail
>> client app and paste.
>
> Couldn't this be solved by the web mail server providing an export feature
> which let the user download the email as an .eml file and open it with their
> mail client?

Of course, that or POP/IMAP access is the way things currently work.

> Again, I don't believe the solution to this requires a copy
> and paste operation.

..but I think it would be more intuitive and user friendly if
something like that worked. (Or drag-and-drop an E-mail from the
webmail to the desktop client/file system/other webmail, which is
basically the same thing).

> However, I'm not sure what problem you're trying to
> solve.  Why would a user want to do this?  Why can't users who want to
> access their email using a mail client use POP or IMAP?

Granted this use case is a bit more far-fetched (but I know people who
copy E-mails from their Outlook and paste in Windows Explorer! - for
"backing up" or archiving a message they want to keep).

-- 
Hallvord R. M. Steen