- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Mon, 10 Apr 2006 14:30:23 -0400
- To: "David Wood" <dwood@softwarememetics.com>, "Ben Adida" <ben@MIT.EDU>
- Cc: "Mark Birbeck" <mark.birbeck@x-port.net>, "public-rdf-in-xhtml task force" <public-rdf-in-xhtml-tf@w3.org>
Name suggestion: HTML-S (The S stands for "Semantic".) I also think a good, descriptive name can help significantly. David Booth P.S. This reminds me of an experience I had at AT&T Bell Labs years ago. AT&T was preparing to launch the next version of a product whose original name I have now forgotten-I'll just call it "Foo" for the moment--so they ran an employee contest to come up with the best name. Many creative and interesting names were submitted. The winner: "Foo-II" > -----Original Message----- > From: public-rdf-in-xhtml-tf-request@w3.org > [mailto:public-rdf-in-xhtml-tf-request@w3.org] On Behalf Of David Wood > Sent: Saturday, April 08, 2006 3:51 PM > To: Ben Adida > Cc: Mark Birbeck; 'public-rdf-in-xhtml task force' > Subject: Re: Save shelfspace with RDF/A [was RE: The RDF/A > Marketing Site] > > > > Hi all, > > I am *horrible* at naming things, but I like the ideas regarding a > name which stresses extensibility, and a relationship to HTML > authors. eXtensible HTML Metadata (XHM) comes to mind, but see the > caveat above. > > Regards, > Dave > > > On 8 Apr2006, at 15:46, Ben Adida wrote: > > > > > > > Mark, > > > > Excellent points. I particularly like having a tag line. > > > > I disagree that the name is meaningless, though. We don't have a > > marketing budget, so having a name that is easy to remember, easy > > to spell, and easy to search for is fairly important. We also want > > to ensure that the name is well targeted to our audience. On both > > of these fronts, RDF/A has issues. The "/" remains a big > issue. And > > the "RDF" will mislead HTML authors into thinking that this is not > > targeted at them. We should consider a name that will be a > bit more > > attractive to HTML authors. That doesn't mean the ones I suggested > > are good, I'm just saying we should take some time to think about > > this. > > > > As for the tag line.... of course I like the one Mark suggests :) > > But again, I wonder if it connotes the wrong thing to HTML authors > > who have, for better or worse, been scared away from the "semantic > > web." I'm thinking "bridging the clickable and semantic web" might > > be best for the semantic web audience, not the HTML authors. > > > > Can we find a way to ease HTML authors into it a bit more? Maybe by > > highlighting how this is different from Microformats? > Extensibility > > comes to mind. Modularity comes to mind. Independence of > publishers > > is also a big deal - It's not about schemas approved by a central > > authority. > > > > I don't have a good suggestion yet, but maybe this will spark more > > ideas from Mark :) > > > > -Ben > > > > On Apr 8, 2006, at 12:10 PM, Mark Birbeck wrote: > > > >> > >> Hello all, > >> > >> In response to Ben's excellent 'kick-start' of a marketing plan, > >> I'd like to > >> say a few things on the naming issue. My comments are in response > >> to general > >> points that that have been made in meetings and on the > list, but I > >> won't try > >> to find all the references since the things I'm saying are pretty > >> general. > >> > >> > >>> 1) A New Name > >>> I support the idea of picking a new name that is more marketable > >>> than 'RDF/A'. This is our last opportunity to think of a > better name > >>> before we have to stick with it. The name should attempt > to convey > >>> some of the following concepts: HTML, web, extensible, embedded. > >>> > >>> Some Ideas to get us started (yes, some of these are > strawmen, but > >>> strawman-status is in the eye of the beholder): HERMES - Html > >>> Embedded Rdf Metadata with ExtenSibility XIM - Xtensible > >>> Interoperable Metadata WebMIM - Web Meta Information Module > >>> WebFormats > >>> > >>> (please submit more ideas!) > >> > >> > >> SHOULD WE CHANGE THE NAME? > >> > >> I have to say I disagree with renaming. Don't get me wrong, I > >> don't think > >> RDF/A is a great name. But naming is such a subjective thing that > >> I will > >> happily take bets that a discussion about names on this list will > >> be a total > >> waste of time. > >> > >> So, my view is that although I have no problems with a name > >> change, I think > >> it will take up too much of our time to discuss, especially when > >> we are > >> unlikely to come up with anything. > >> > >> > >> DO WE *NEED* TO CHANGE THE NAME, ANYWAY? > >> > >> The thing about names is that it really does not matter: people > >> happily buy > >> and rent 'DVDs'; they discuss whether they need more 'RAM'; some > >> years ago > >> my mum told me that she had decided to upgrade her computer to 'a > >> 486'; > >> people lean across the table in the pub, pick up a > friend's phone, > >> and say > >> "Oh, you've got the new 3250". > >> > >> None of this is to say that if someone came up with a fantastic, > >> descriptive > >> name it wouldn't get my vote--I'm not saying it *must* be called > >> "xcmm3" or > >> something obtuse, just for the sake of it. But unless the name is > >> light-years ahead of "RDF/A" I don't see the > point--picking on the > >> strawmen > >> "HERMES" and "XIM" for example, they don't actually convey > >> anything about > >> what we're doing. > >> > >> > >> SO I DON'T CARE ABOUT MARKETING? > >> > >> Far from it. But the reason I want to sound an air of caution is > >> because > >> what often happens is people start to believe that something will > >> *only* be > >> successful if it has a funky name, and I don't want us to fall > >> into this > >> trap. If the technology of 'RDF/A' is successful it will be > >> because the > >> examples are clear, the use cases are broad, the requirement is > >> widely > >> present, early adopters are vocal, and so on. That's 'real' > >> marketing and > >> gives us the best chance of success. If we achieve success it > >> won't be down > >> to the name. > >> > >> > >> THE 'ELEVATOR PITCH' > >> > >> Whilst the name of our technology will make close to zero > >> difference to its > >> adoption, the one-liner--so-called elevator pitch--could. Putting > >> on an old > >> Disney video for my son to watch the other day, I was > surprised to > >> see that > >> one of the opening adverts was from Disney itself telling you how > >> you could > >> now get all of its films on DVD, and they took up far less space > >> on your > >> shelves than videos! > >> > >> I don't recall if that was the standard way of extolling the > >> virtues of DVDs > >> when they were new, and of course it sounds laughably dated now > >> that DVDs > >> are so commonplace. But it's a good illustration of how the name > >> is less > >> significant than the benefits that something offers. > >> > >> So for me the thing to 'capture' is finding that sentence--in > >> other words, > >> how much shelf-space does RDF/A take up? > >> > >> One strong candidate is something Ben said ages ago which is the > >> idea of: > >> > >> "bridging the clickable and semantic webs" > >> > >> The key thing about the 'elevator pitch' is not that it conveys > >> *all* of our > >> ideas, but that it gives us a constant base, a foundation, > onto which > >> everything else is layered. So we know that RDF/A is 'more' than > >> just making > >> clickable links semantic, but we can explain all of that on the > >> new site. > >> What we're looking for here is something that (a) keeps us > focused > >> when we > >> plan to write about it, do presentations on it, write > tutorials or > >> give > >> examples on it, and (b) is the thing that we always ensure people > >> take away > >> about RDF/A, even if they take away nothing else. > >> > >> I would say that of all the things that RDF/A can do, at this > >> moment in time > >> [*] it is the ability to derive semantic information from links > >> that have > >> been placed in a 'normal' document, that is probably key. I think > >> this > >> 'base' idea contains within it everything about > 'embedding', using > >> current > >> mark-up, ease of authoring, unlimited formats (not the four > >> microformats), > >> decentralisation (rather than the centralised nature of > >> microformats), and > >> so on. > >> > >> So even if we were to continue with a renaming exercise, > I'd strongly > >> recommend that the process would have to begin with finding this > >> one-liner > >> first--we need to know what we're selling before we can name it. > >> > >> [*] I say "this moment in time" only because there is no reason > >> why the > >> 'pitch' might not change in the future and some other feature get > >> brought to > >> the fore. > >> > >> > >> SUMMARY > >> > >> Success is not going be based on the name, but on having a clear > >> message > >> about what the *purpose* of RDF/A is and what it lets you > do that you > >> couldn't do before. Getting bogged down in naming is not a great > >> use of > >> time. > >> > >> We do however, need to agree on our 'elevator pitch'. If a name > >> flows from > >> that then great, but the one-liner is crucial. My vote goes for > >> something > >> like: > >> > >> "RDF/A bridges the clickable and semantic webs." > >> > >> "RDF/A: bridging the clickable and semantic webs." > >> > >> (I really like the second one, and I think "Bridging the clickable > >> and > >> semantic webs" would be a good strapline for the forthcoming web > >> site--it > >> conveys a nice active sense, since we know that these two webs > >> *need* to be > >> bridged, and we also know that up until now they haven't > been, and > >> we know > >> that we have more work to do.) > >> > >> Hopefully Ben hasn't trademarked these, since my backup suggestion > >> is not so > >> good: > >> > >> "RDF/A takes up less room on your shelves." > >> > >> Regards, > >> > >> Mark > >> > >> > >> Mark Birbeck > >> CEO > >> x-port.net Ltd. > >> > >> e: Mark.Birbeck@x-port.net > >> t: +44 (0) 20 7689 9232 > >> b: http://internet-apps.blogspot.com/ > >> w: http://www.formsPlayer.com/ > >> > >> Download our XForms processor from http://www.formsPlayer.com/ > >> > >> > >> > > > > > > >
Received on Monday, 10 April 2006 18:34:21 UTC