Re: tensions between copy-and-paste and follow-your-nose [Fwd: Re: profile attribute and conformance (copy-and-paste details)]

This is probably not very well considered, but my initial reaction is 
that, to get this right, we need to distinguish a notion of "meaning in 
isolation" from "meaning in context".  In isolation, the  <dl 
class='hpayment'> does indeed represent a payment.  If one extracted an 
RDF triple indicating: somewhere in this document is mention of a payment 
to the Order of Ben Fraudster, that would be a correct statement (or if 
that's not quite right, you could come up with a statment that is.)   That 
same statement would be necessarily be true of a document into which you 
pasted a copy of that same fragment.  In the context of the document as a 
whole, the payment is labeled as fraudulent.  Thus an RDF triple conveying 
"This document represents a fraudulent check to Ben Fraudster" would be 
correct.   What's incorrect is to imply in context meaning from 
information taken in isolation:  a triple saying "A correct payment was 
made to Ben Fraudster" is not a correct inference from this document.

My intuition is that it's the user agents, or in the case of copy/paste, 
the combination of sending and receiving user agents, that knows the 
context.  If I copy a whole document to a clipboard, and paste it as a new 
document in a receiving application, then ,(modulo quibbling about 
dependencies on the base URI) any triples that can be inferred from the 
source are presumably inferrable from the target too. 

If instead a user makes a selection corresponding to a subtree in the 
source, and pastes that, then presumably the user agent needs some way of 
conveying on the clipboard that a fragment is being conveyed out of 
context;  if the receiving user agent is going to try and use GRDDL on the 
pasted fragment, then there would have to be some way for that agent to 
discover transforms that the original document author warrants are 
applicable to the fragments in isolation.  What's missing, it seems, is a 
way to author, publish and associate such additional transforms with the 
original document.  I have no bright ideas as to how to do this, or 
whether it's worth doing.  One could imagine ways of structuring or 
annotating the original GRDDL with some sort of rule based mechanism that 
would allow an engine to determine automatically the conditions under 
which certain templates could be safely applied to which fragments in 
isolation and/or after pasting into other documents.  One could also 
imagine alternate linking mechanisms, perhaps including links sprinkled 
throughout the original content.

I don't know if that's helpful, but it's how I find myself thinkinging 
about the problem given that you've raised it.  In particular, it doesn't 
seem to me that anything is "broken", in the sense that mechanisms have 
been designed poorly or layered wrong;  it just seems that publishing 
transforms for use on fragments is an additional feature that might be 
needed, and hasn't been specified yet.

> p.s. I don't know if this crossed your radar...
> The details of data in documents: GRDDL, profiles, and HTML5

Nope, but it's interesting.  Thanks!


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Dan Connolly <>
Sent by:
09/05/2008 06:50 PM
        To:     www-tag <>
        cc:     public-grddl-comments <>, 
(bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        tensions between copy-and-paste and 
follow-your-nose [Fwd: Re:      profile attribute and conformance 
(copy-and-paste details)]

Noah, while you've got the self-describing web stuff swapped
in... attached find an example of follow-your-nose
issues within a document. (cf xmlFunctions ISSUE-34).

I don't expect it's worth space in the finding, but I'd
like you to look it over and let me know if it makes sense.

p.s. I don't know if this crossed your radar...

The details of data in documents: GRDDL, profiles, and HTML5

Dan Connolly, W3C
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

----- Message from Dan Connolly <> on Fri, 05 Sep 2008 
12:01:58 -0500 -----
Ryan King <>
Henri Sivonen <>, Michael Smith <>, HTML WG 
Re: profile attribute and conformance (copy-and-paste details)

On Thu, 2008-09-04 at 10:23 -0700, Ryan King wrote:
> On Sep 4, 2008, at 7:54 AM, Henri Sivonen wrote:
> > In general, having the URI at the top of the page source and the 
> > microformat later in the body goes against the view source copy and 
> > paste way of learning HTML and also goes against the restrictions of 
> > blogging systems that allow people to paste stuff somewhere in the 
> > body but not control the head of the page.
> To get around this issue, there's a proposal on the microformats wiki 
> [1] that would allow profile URIs to be placed in the body.

That will probably work in a lot of cases, but consider something like:

  <h2>Exhibit A: the fraudulent check</h2>
   <dl class='hpayment'>
    <dt>Pay to the order of:</dt>
    <dd class="hcard">Ben Fraudster</dd>
    <dt>rounting number</dt>
    <dt>account number</dt>
   <p>This is a <a rel="profile" href=
          "">UCC electronic

The check is quoted within another legal document. The author
of the outer legal document doesn't mean to offer payment
but to say "look at that check; it's bogus."

I expect this sort of thing is in the noise for upwards of 80% of
the cases, so I don't expect it to get much consideration
in the design of HTML 5.

But GRDDL was designed as a long-tail mechanism.
The GRDDL WG looked at a number of ways to push the profile
signal down from the top of the document to facilitate cut-and-paste
but found that each of them conflicted with the
"faithful rendition" requirement and postponed the issue.

issue-tx-element: is there a way to push the grddl:transformation
attribute down from the document element to individual elements without
breaking the chain of authority? 
POSTPONED 2007-01-17

I had a tooth-brushing-thought about using visible icons somehow...
but I haven't really finished it...

> -ryan
> 1.

Dan Connolly, W3C
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 10 September 2008 01:04:27 UTC