Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

Hi Pat,

OK, yelling heard loud and clear :)

By way of concrete actions, I gave Ivan Herman a (probably unfairly)
hard time today here at Dagstuhl to 'encourage' the authors of the
Vocabs Best Practices to press on with the revision of that document
that addresses the current issues. An update of the "How to Publish
Linked Data on the Web" tutorial is also on the cards; perhaps one of
the outcomes of this revision could be a greater emphasis on the hash
URI pattern (and maybe also the 'health warning' you describe ;).



2009/6/29 Pat Hayes <>:
> On Jun 28, 2009, at 6:20 PM, Tom Heath wrote:
>> Hi Pat,
>> 2009/6/25 Pat Hayes <>:
>>> With the sincerest respect, Tom, your attitude here is part of the
>>> problem.
>>> Maybe, along with many other people, I am indeed still stuck in the
>>> mid-1990s. You have permission to be as condescending as you like. But
>>> still, here I am, stuck. Thoroughly stuck. So no amount of condescending
>>> "sooo-20th-century, my dear" chatter is going to actually enable me to
>>> get
>>> to a place where I can do what you think I should be doing.
>> Condescension was never my intention here. My goal was to draw a
>> comparison that might enable us to learn a lesson from the history of
>> the Web and use that to help us move forward. As Mark described, over
>> the course of time more and more tools became available that made it
>> easier to publish HTML. Presumably these only arose because publishing
>> HTML was to some degree hard. The Web community has gone through this
>> process once already; let's learn the lessons from last time and apply
>> them to publishing RDF so people don't have to be stuck any more.
> Um.. I thought that was MY point :-)
>> Dan
>> outlined some technical approaches to doing this sort of thing. Some
>> domain-specific apps already exist that (hopefully) reduce the pain;
>> it was one of the goals of for example.
>>> I cannot use a
>>> rewrite rule to catch incoming requests, or do whatever you are talking
>>> about here. I live in an environment where I simply do not have access at
>>> all to the workings of my server at a level that close to the metal,
>>> because
>>> it is already woven into a clever maze of PHP machinery which is too
>>> fragile
>>> to allow erks like me to mess with it. Some of the best W3C techies have
>>> taken a look, and they can't find a way through it, either. Maybe Im in a
>>> special position, but I bet a whole lot of people, especially in the
>>> corporate world, are in a similar bind.
>> You're talking about two very different groups here. If the right
>> tools are created then individuals will presumably adopt some
>> specialised SaaS analogous to say Corporations are a
>> different kettle of fish
> I work for a small research company which happens to have an ambitious
> Webmaster and a Director who is sensitive to visual graphics and Web image
> issues. The result is a maze of complex PHP giving users a very nice
> experience, but not conducive to transparent use by its inhabitants. Just
> from casual Web browsing, I cannot believe that I am in a very small
> minority. There are a lot of 'sexy' sites out there that must be in a
> similar state. I know that several 'web authoring' systems produce similar
> PHP mazes, because Ive tried using them and then editing the output they
> produce, an experience rather like debugging BCPL.
>> , but just as many built their own Web-serving
>> infrastructure in the 90s, so they will invest in publishing data to
>> the Semantic Web if they perceive adequate value (demonstrating that
>> value is where we need to be working even harder!).
>>> System level access to a server is
>>> quite a different beast than being allowed to publish HTML on a website
>>> somewhere. I can, and do, publish HTML, or indeed just about any file I
>>> like, but I don't get to insert code. So 6 lines or 600, it makes no
>>> difference.
>>> But in any case, this is ridiculous. RDF is just XML text, for goodness
>>> sake.  I need to insert lines of code into a server file,  and write PHP
>>> scripts, in order to publish some RDF or HTML?  That is insane. It would
>>> have been insane in the mid-1990s and its even more insane now.
>> No. This is incorrect. This discussion only applies to the
>> 303-redirect/slash URI pattern. You can avoid this completely by using
>> the hash URI pattern as someone mentioned (sorry for not crediting
>> directly, getting hard to navigate this thread).
> Yes, of course, and I apologize for overstating the case. Still, the
> slash-URI seems to be much more acceptable to many unsemantic Webbies, who
> are used to thinking of URIs as being stripped of their post-hash content at
> the slightest internet shiver, so don't regard a name including a hash as
> something 'real'; and it is the case about which all the fuss is being made.
> If the published advice was: always use hash URI patterns, I would be happy.
> But the published advice *starts* with 303 redirects and .htaccess file
> modifications.
>>> IMO, it is
>>> you (and Tim and the rest of the W3C) who are stuck in the past here.
>>>  Most
>>> Web users do not, and will not, write code. They will be publishing
>>> content
>>> in a cloud somewhere, even further away from the gritty world of scripts
>>> and
>>> lines of code than people - most people - are now. Most actual content
>>> providers are never going to want to even know that PHP scripts exist,
>>> let
>>> alone be obliged to write or copy one.
>> You've over-interpreted my words here. See above.
> If so, I apologise. But think of what Im saying as a cry for help. There are
> a lot of people like me, I suspect, who would really like to help with SW
> deployment and are willing to write RDFa content, but are paralyzed by the
> apparent need to become Web-server hackers in order to do so. It just feels
> *wrong*. Your own metaphor is apt:
>>> Martin is exactly right: this is a
>>> MAJOR bottleneck to SWeb adoption. Its up to the people in the TAG to
>>> listen
>>> to this fact and do something about it, not to keep issuing useless
>>>  'best
>>> practice' advice that cannot be followed by 99% of the world.
>> I think that's overplaying things. It's like saying "stop issuing best
>> practices for cardiac surgeons because Average Joe can't use those to
>> help improve his cardiac health".
> Well, yes, exactly. Im not a cardiac surgeon, and here I am reading this
> stuff that I naively took to be good advice for improving my cardiac health.
> It didn't say: For Surgeons Only on the cover. If the SWeb is going to rely
> on cardiac surgeons rather then average Joes to get all that RDFa written,
> then its never going to happen.
>>> RDF should be text, in documents. One should be able to use it without
>>> knowing about anything more than the RDF spec and the XML spec. If it
>>> requires people to tinker with files with names starting with a dot, or
>>> write code, or deploy scripts, then the entire SWeb architecture is
>>> fundamentally broken.
>> The architecture of the Semantic Web is the architecture of Web. And
>> just as in the Web we have varied publishing patterns/workflows
>> (ranging from simple to hard), so we will in the Semantic Web.
> But, and this is where this thread started, right now we don't seem to have
> any easy ones at all. All my yelling has been to try to get you guys to take
> this issue as seriously as I think it deserves to be taken.
> Best wishes
> Pat
>> Cheers,
>> Tom.
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit

Dr Tom Heath
Platform Division
Talis Information Ltd
T: 0870 400 5000

Received on Monday, 29 June 2009 22:16:51 UTC