- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 19 Oct 2010 16:45:18 -0200
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
- Message-Id: <6B9AB4A1-F42A-4EDE-A278-1F8331985D06@w3.org>
(Having some time in meeting breaks) In http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0109.html Nathan proposed an alternative, essentially making the issue more explicit. Taking his example, and Shane's earlier remark, a possible text might be: [[[ After processing, the triples similar to the following will be generated: _:john foaf:mbox <mailto:john@example.org> . _:sue foaf:mbox <mailto:sue@example.org> . _:john foaf:knows _:sue . Note that when these triples are serialized, or accessed via an RDFa API, the identifiers "_:john" and "_:sue" may be exposed through some other, implementation dependent identifiers. The only feature that an implementation is required to keep is that the identifiers for the two blank nodes are different. ]]] Ivan On Oct 19, 2010, at 14:59 , Mark Birbeck wrote: > Hi Ivan, > > Yes...sigh...deja vu...etc., etc. > > I think the prose is actually fairly accurate. It says that two bnodes > are created, and that those bnodes are referenced. We don't say > anything here about what goes on inside a processor to generate those > bnodes. > > The problem we have is to try to explain what triples are generated > from a particular piece of markup. All of our examples are talking > about triples going *in* to a triple-store, and for that we need to > ensure that the bnode identifiers are the same as in their > corresponding examples -- otherwise it simply doesn't make sense. > > However, when you serialise *out* of a triple-store, I agree with you > that a different bnode identifier could be used. > > But you can't help people understand this by suddenly changing an > example halfway through so that it uses _:x instead of _:john...that > breaks the example! > > If you want to make it clear to people that the examples are showing > serialisations on the way *in* to a triple-store then by all means > propose some wording. > > But that's very different to changing the examples. > > Regards, > > Mark > > > On Tue, Oct 19, 2010 at 5:26 PM, Ivan Herman <ivan@w3.org> wrote: >> Sigh. I have a feeling of deja vu, and we seem to repeat the same arguments. >> >> The document says: >> >> [[[ >> <link about="_:john" rel="foaf:mbox" href="mailto:john@example.org" /> >> <link about="_:sue" rel="foaf:mbox" href="mailto:sue@example.org" /> >> <link about="_:john" rel="foaf:knows" resource="_:sue" /> >> >> In the above fragment, two bnodes are explicitly created as the subject of triples. Those bnodes are then referenced to demonstrate the relationship between the parties. After processing, the following triples will be generated: >> >> _:john foaf:mbox <mailto:john@example.org> . >> _:sue foaf:mbox <mailto:sue@example.org> . >> _:john foaf:knows _:sue . >> ]]] >> >> Ie, the text says "the following triples will be generated". This statement is purely and simply wrong. The generated triples are a serialized version of the triples and by saying 'will be generated' and using the same identifiers, a casual reader may deduce that the identifiers are the same as in the original RDFa source. It also suggests that >> >> [[[ >> _:x foaf:mbox <mailto:john@example.org> . >> _:y foaf:mbox <mailto:sue@example.org> . >> _:x foaf:knows _:y . >> ]]] >> >> is wrong. >> >> While this may not be very important for RDFa Core, because people do not necessarily care about the generated turtle or RDF/XML code which is usually brought into an RDF system, but if this perception is taken over to the RDFa API then we may have real problems. >> >> I do not care about a slight inconsistency in the document if such false impression are given by the current document. >> >> Ivan >> >> >> On Oct 19, 2010, at 09:35 , Mark Birbeck wrote: >> >>> Hi Ivan, >>> >>> On Tue, Oct 19, 2010 at 11:41 AM, Ivan Herman <ivan@w3.org> wrote: >>>> >>>> On Oct 19, 2010, at 08:00 , Mark Birbeck wrote: >>>> >>>>> Hi Ivan, >>>>> >>>>> But at the telecon we agreed not to change the examples. >>>>> >>>> >>>> I have not seen minutes. >>>>> Obviously I'll wait to see what this wording is, but based on previous >>>>> discussions my argument was that the bnode identifiers in the prose >>>>> and the serialisation needed to be consistent. >>>> >>>> I am sorry, I strongly disagree with that. The current text is misleading for the casual reader of our spec (who will strongly rely on the examples) and giving a wrong impression via examples is a source of trouble. I do not see any consistency issue here, and even if there was, I would disagree with that argument. >>>> >>>> _Something_ should be said in the examples that people should not rely on the bnode identifiers. I fully trust Shane to find the best editorial approach. But the current text is not acceptable in my view. >>> >>> But what does it mean to "rely on bnode identifiers"? >>> >>> How do you get a bnode identifier? How do you manipulate them? >>> >>> It's like saying that JavaScript programmers shouldn't rely on >>> variable names; yes of course you can tell the novice programmer that >>> variable names can change without affecting functionality. But don't >>> whatever you do create sample code where the variable name changes in >>> the middle of an example. >>> >>> The corollary for RDFa is that if we begin an example like this: >>> >>> <div about="_:ivan" ... >>> >>> then when we talk about the triples generated by that example we >>> *must* use _:ivan in our explanations. >>> >>> This says nothing about the triple-store, or the implementation >>> specifics about bnodes, because we're just using bnode identifiers, >>> and they are simply placeholders. >>> >>> I've explained elsewhere on the list that if you don't retain >>> consistency then it's like starting a JavaScript tutorial on addition >>> like this: >>> >>> var a = 10; >>> >>> before going on to say that we can add 10 to this variable, like this: >>> >>> b = b + 10; >>> >>> Why did we change the name of the variable in mid-example? Apparently >>> because we didn't want readers to have the false impression that all >>> variables have to be called 'a'. :) >>> >>> (Note that all of this is separate from our other discussion about >>> what _:ivan generates internally in the graph.) >>> >>> Regards, >>> >>> Mark >> >> >> ---- >> Ivan Herman, W3C Semantic Web Activity Lead >> Home: http://www.w3.org/People/Ivan/ >> mobile: +31-641044153 >> PGP Key: http://www.ivan-herman.net/pgpkey.html >> FOAF: http://www.ivan-herman.net/foaf.rdf >> >> >> >> >> >> ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 19 October 2010 18:45:10 UTC