Category: Technology

Categories
Technology

PHP/MySQL Help

Recovered from the Wayback Machine.

My system has MySql 2.23.51, Apache 1.3, PHP4, FreeBSD, and I’m running into problems trying to update or insert into MySql with PHP. The update or insert works, but I get warning back:

Warning: MySQL: Unable to save result set

The change is saved, but the application breaks. No error message is generated in log, no error number is returned. I can insert or update using Perl without a problem.

I researched the problem and tried compiling PHP as a shared Apache module — and not. I’ve used PHP’s default MySql libraries, and have also tried local MySql libraries.

I’d sacrifice a chicken at midnight, if I thought this would work. Anyone recognize this problem? Suggestions?

Categories
Technology Weblogging

Consumer rights and RSS

Recovered from the Wayback Machine.

Yesterday was a disappointing technology day. I had hoped to use the position of devil’s advocate at the RSS-Dev group to see if we couldn’t get a firmer definition of what the group sees as its future direction, strategy, as well as specific reasons for use of RDF. I continue to see confusion reign as to a) what the group sees as its purpose, and b) what the group sees as its direction.

Last week, I found I was having a hard time justifying the use of RDF for throwaway syndication feeds. I’ve always felt that if you can’t easily justify something, or provide a solid argument in support, either you don’t understand the need, or there isn’t a need — one or the other. At this point, I couldn’t continue to support RDF for throwaways.

Phil found out in the last two weeks of very hard effort that sometimes RDF just doesn’t work for a specific application. Doesn’t mean RDF is ‘bad’ — I use it for 3 applications at my web sites and it’s wonderful stuff. But RDF isn’t a replacement for XML. Sometimes XML works better. Sometimes plain text works better. If we start developing an attitude of “It’s on the web, so let’s put it into RDF”, we’re guilty of using the right technology for the wrong task, which doesn’t benefit anyone.

Now, I can support RDF for a different type of business, such as persistently documenting each weblog or news item posting, using something that is Dublin Core like, but geared more towards the document sub-unit business. This then could be used for traditional syndication/aggregation, but would primarily be used to literally document our content — for searches, for identification, for whatever. And I tried to get the RSS-Dev group to bite off on this as a possible direction, but in the end I was left with “we’re syndication/aggregation”, or in another case, “we’re RSS and the purpose of this group isn’t justification but tools development”.

Making a long story short: though I respect many of the individuals involved with RSS 1.0, their effort and hard work and intelligence and capability as well as energy, I can’t continue to support RSS 1.0 or RSS-Dev. Not with this current level of confusion about what the group sees as its purpose.

Unfortunately, not supporting RSS 1.0 is seen as giving victory to Dave Winer at Userland, by forcing us into choosing an RSS 0.9x/RSS 2.0 path. However, I still don’t approve of Dave’s approach to implementing RSS and his unwillingness to give up ownership of it. I can respect Dave’s contribution, and his hard work and effort, and his intelligence and capability, but I can’t support a supposedly ‘open’ spec that’s controlled by one company.

Ultimately, supporting either specification means, to me, continuing to support this competition between the groups, competition which threatens to Never…Go…Away, as can be seen in the comments to Phil’s posting.

Sometimes, when I read these types of comments, I feel as if you and I don’t matter at all; that you and I are nothing more than scraps of meat being fought over by two junk yard dogs. Well, this just peeves me. So, I’m taking the route that’s been available to consumers since the beginning of time: I’m not buying.

I’m not buying into RSS 0.9x. I’m not buying into RSS 2.0. I’m not buying into RSS 1.0.

I changed my RSS 0.91 and RSS 1.0 templates to read the following:

 

RSS not supported here

This weblog does not support RSS 0.9x, RSS 2.0, or RSS 1.0. If you wish to view entries, may I suggest that you visit the weblog, and save your fast skimming for the New York Times and Wall Street Journal.

 

My weblog. My web sites. My choice.

Categories
Web

Who is your audience and what are you trying to accomplish?

Recovered from Wayback Machine.

Just posted the following over at RSS-Dev (edited to remove typos):

There seems to be three separate threads running along the lines of “Who are we and what are we trying to accomplish”, mixed in with proofs and justification of keeping RDF in the mix. How can the energy expended into these threads be coalesced into a determined course?

I asked the question, here and elsewhere, who is your audience? This isn’t marketing or make work. This is a genuine attempt to understand what this group hopes to accomplish other than working with cool technology for the sake of the technology. What is the business of this group?

If RSS, past and current, is based on providing syndication and aggregation feeds, and nothing more, than I agree with those that say RDF adds nothing to the mix, and not because RDF adds complexity — the reason is because the business of RSS isn’t necessarily compatible with the business of RDF.

In the last few weeks, Phil Ringnalda has been working on a application to process RSS 1.0 files and combine this with FOAF to provide a sophisticated interface allowing us to find who has posted or commented on what topic. Yesterday he hit what is probably the core difference between the business of RSS and the business of RDF — the fact that tools generate labels for blank nodes, and that these labels will vary each time the same file is parsed. (See
http://philringnalda.com/archives/002327.php). RDF/RSS (RSS 1.0) has blank nodes.

RDF is a meta-language for describing items that exist in such a way that this data can be processed with the same set of tools and combined with a great deal of confidence that this mergence results in a valid pool of rich data. It is literally a markup version of the relational data model, and as such, is extremely useful and necessary to help with the chaos that XML created. However, there is an implied persistence to the items described with RDF, the same as there is with relational databases. Data may change and be removed, but there is no temporal self-destruct attached to the items.

RSS, as the majority of those who view it (the users, not the tool developers) is a syndication feed — nothing more than recently updated items that can be polled and aggregated. There is no implied persistence. In fact, the business of RSS is based on impermanence.

This is a major difference in ‘business’ between the two concepts. From a database perspective, this is equivalent to using an RDBMS when a flat file of comma-delimited data is all you need.

If this group wants to continue providing a specification that defines syndication feeds, then it needs to consider that RDF not only doesn’t buy the group anything — it can harm the tool developers that use the spec. (Not to mention that trying to use RDF inappropriately can actually negatively impact the acceptance of the RDF specification.)

If, however, this group sees that what they’re working on transcends throwaway syndication feeds, then it needs to formally define exactly what the business is _before_ trying to create a spec that implements it. Hence my questions: who is your audience and what are you trying to accomplish?

Specific instances of technology aren’t an answer to these questions. This isn’t answered by, “Well, we’ll just continue as is and use XSLT to handle any problems in the future” or “We’ll use modules”. If you find yourself answering these questions by referencing technology, then either you’re missing the point, or (more likely) I’m doing a piss-poor job of explaining myself.

What is the problem this group is trying to resolve? What is the benefit this group is trying to provide that no other technology or specification provides? Who is your audience? Not the tool developers — people don’t write tools for no reason. Who are the consumers of the tools developed?

What are you trying to accomplish?

This understanding of the basic business goes beyond a name, though the name of ‘RSS’ is drastically adding to the problem by forcing a type of business on this group that this group really doesn’t want, as well as adding an element of competition that is both unnecessary and harmful.

Perhaps this group really isn’t interesting in throwaway syndication feeds. Perhaps this group is interested in finding ways of describing publication units that may or may not be smaller or bigger than an individual web page, and a side benefit of this is that the data can be used for aggregation purposes. Or not. I don’t know — the group hasn’t told me what the business is.

If you continually have to justify the use of something over and over again, either you’re wrong, or your audience is wrong. In either case, you need to re-focus your efforts, and either find a different audience, or stop beating a dead effort.

Categories
Web

The turbulent waters of RSS

Recovered from the Wayback Machine.

I was pleased and rather surprised to see so many comments attached to my posting on RDF. As to be expected with recent discussions, the thread soon turned to issues of RDF/RSS. That’s cool.

What isn’t cool is something such as this by Morbus Iff and Dave Winer’s absolutely atrocious response. Saying something such as:

Anyone who works with Hemenway or Kearney should be aware that these people are nothing less than monsters, who will stoop to any level to get their way. Their perversion may even be the reason they’re involved.

Over the line. What I especially can’t understand with the essay is why Dave brought Ben Hammersley into this particular discussion. The reason looks to be because Ben didn’t include Radio in the RSS aggregators discussed in an article he wrote for The Guardian. Dave called Ben’s article tainted just because Radio — which is a weblogging tool, not a pure news aggregator — wasn’t mentioned.

Calling Morbus on inappropriate joking is one thing. Publishing Morbus’ name, attacking Ben, and calling Bill and Morbus ‘monsters’, is another.

The RSS discussion continues I gather over at Blogroots as well as RSS-Dev.

Time to move on. Let Userland have RSS if they wish. The folks involved with RDF/RSS should come up with a different name, as simplified a syntax as possible that is still valid RDF, and let folks use what they want. If some folks want to use XSLT to transform RDF/RSS to Userland RSS, or the reverse, fine. But this is a technical trick and kludge and shouldn’t even be considered as part of a specification.

I would also strongly recommend that the newly renamed and reformed RDF/RSS working group define the intent and focus of RDF/RSS so that it doesn’t become “one XML to rule them all”, in their interest of creating the perfect syndication format. And since the group would be in the process of many changes, I would also suggest that the RDF/RSS working group move their discussions to another venue other than Yahoo groups, with all its many annoying ads. It’s becoming increasingly difficult to follow the threads: the quotes from previous messages overwhelm the new content, the mix of discussions about spec minutia and group working matters with grand overall schema changes is perplexing and off putting to new people getting involved, and on and on.

It’s also past time for the RDF folks, other than just Dan Brickley, to start getting involved. In particular, I wouldn’t mind seeing the RDF working group folks with weblogs. I have found this to be an excellent format for opening conversations with one’s target audience.

As for myself, I’ll only support an RDF-based aggregation newsfeed at my web sites because I believe this is the better approach. If this means my feeds aren’t readable by some aggregators, okay, I can live with this. This will be an unfortunate side effect on not being able to pull reasonable people together to come up with a combined specification (and note that I don’t consider that a lot of the players in this little farce to be ‘reasonable’, a statement thereby pissing off all participants equally).

Personally, I think a widening of this particular rift is a positive rather than a negative event.

Postscript: You know, there are no women involved in the RDF/RSS working group or the RDF working group. I think this should change. Perhaps I should lurk less and talk more. Any other lady techs in the audience wish to join me?

Categories
Semantics Technology

RDF: As simple as A, B, C

When I demonstrated a very simplified RDF/RSS model last week, in the comments attached to the post, Ziv asked the following question:

One question of an RDF newbie: Why do we need that (rdf:Description) element? Why can’t we simply put the @rdf:about attribute on the (item)?

As I started to answer the question in the comments, I kept finding myself taking the question deeper and deeper into the meanings of RDF:

-The rdf:about attribute can’t be used directly on a property led to

-The RDF/XML follows a striped XML syntax of class/property/class/property, regardless of shortcuts led to

-The striped XML syntax is based on the pattern of node-edge-node in RDF led to

-The node-edge-node of RDF is based on a model

All of which led me to a truly definitive question about RDF — why? Why the use of rdf:about here rather than there. Why the syntax? Why the model? After all, XML is a piece of cake — an element here, an attribute there, slam dunk in some text and hey now, we got data. Why make things more complex than they need to be?

Why? Because XML is great about collecting data but is lousy about recording knowledge. There is no facility inherent within the plain vanilla flavor of XML that allows one to write or read assertions in such a way that these assertions (read this as ‘statements’) can be machine produced and machine-readable. And the machines need all the help they can get.

We humans don’t need a rigorous model to communicate. We have phonemes that form words that make up a vocabulary, members of which are then used to form sentences through the use of this really irritating set of rules called “grammar”. We’re programmed to apply these rules through years of instruction, using a neural networking technique called ‘education’. When programming is finished, and after passing certain quality assurance tests, we’re set upon the world. Once loosed from the constraints of the lab, we promptly and as quickly as possible throw out much of what we’ve learned in favor of imagination, creativity, and a dangerous little nugget called innovation.

I love it.

Dorothea wants to discuss her specific mindset related to ‘sexism’ and the concept of sexiness and uses a new word: grunch. This word doesn’t exist, but we as humans adapt to it, add it to our vocabulary (phonemes: grrr + unch). In future writings based on Dorothea’s original discussion, we know what grunch is. Humans adapt.

In 1986, Hans Gabler made 2000 ‘corrections’ to James Joyce’s Ulysses. Well, thank goodness he did because nobody read it the way it was, all those grammatical errors and typos kept getting in the way. Most likely no one even heard of this book until Mr. Gabler took it in hand. As grateful as I am, though, I have recently discovered an even better re-write of this classic: Ulysses for Dummies.

I digress. XML and RDF.

With XML I can record pieces of data such as date, an excerpt, a title, author, category and so on. The structure of the markup allows machines to read these individual facts, to verify that the recording meets certain simple rules. But what if I want a little more than just plain facts. What if I want to be able to take these facts out for a spin, kick the tires, check under the hood?

I have a web page. Facts about this page are: title, URL, date edited, category, and author.

Page has title. Page has URL. Page has edit date. Page has author.

Tarzan has Jane. Jane has Cheeta. Cheeta has banana. A pattern is beginning to emerge.

Every sentence has a subject and a predicate. The subject is the focus of the sentence, and the predicate says something about the subject. These two basic components work remarkably well in allowing us to communicate, to share amazingly complex knowledge.

Returning to RDF and XML, using straight XML is equivalent to only allowing communication with one verb — To Have. Following this, an XML translation of the previous paragraph would be:

Sentence has subject. Sentence has predicate. Sentence has focus. Subject has focus. Predicate has information. Subject has information. Predicate has subject. Components have power. Communication has components. We have each other.

As you can see, after a time, the simplicity breaks down — we need to increase our capabilities, even though doing so adds complexity.

Enter RDF, providing a structure and a meta-language to XML, a grammar if you will.

RDF has one pattern: (subject)(predicate)(object). However, this pattern gives us the tools to record data in such a way that knowledge can be inferred mechanically, merged via a well understood and defined logic with other knowledge, and so on. The subject is the noun, the focus of the statement; the predicate says something about the subject; the object is what is said.

Taking the test paragraph, it can be re-written into the following RDF-like statements:

(Sentence) (has a component)(which is a subject)
(Sentence) (has a component)(which is a predicate)

— no, no, don’t worry — it does get better

(The subject)(is the focus of)(the sentence)
(The subject)(is described by)(the predicate)
(Sentence Components)(enable)(communication)
(Sentence Components)(enable sharing)(of knowledge)

By providing the ability to record this subject-predicate-object pattern, RDF allows us to expand on the depth of information we gather. The more complex the information, the deeper the pattern is applied, but it is still this triple. In a graphical context, the subject-predicate-object form into a node-edge-node that allows us to build new statements on previously occurring ones.

The focus OF the sentence IS the subject DESCRIBED BY the predicate WHICH IS a component OF a sentence. Consider in this sentence that the predicates are the capitalized value, the graphical notation of this could be: node-predicate-node-predicate-node-predicate-node-predicate-node-predicate. Nothing more than a repetition of our friend the triple, connected end to end.

Representing this within XML requires a set of syntactic rules that ensure we don’t accidentally shove a predicate next to a predicate and so on. There are rules for how to identify a subject, and how to add a predicate. There are rules for how to repeat properties (predicate-object pairs), and how to group properties. There are even rules for how to create a statement about a statement (known in RDF as ‘reification’, though I prefer ‘RDF’s Big Ugly’, myself). But fundamentally the rules break down into nothing more than node-edge-node-edge-node, forming a particularly interesting XML pattern called The Striped RDF/XML syntax.

Rule’s that basically say that predicates can’t be nested directly beneath predicates (edges next to edges) or that whole node-edge-node thing gets blown out of the water. And rules that state when an rdf:about attribute can be applied. In my simplified RDF/RSS, the rdf:about attribute can’t be applied directly to the ITEM element because ITEM in this instance is acting as a predicate, with an implied URI of “item” — it can’t act as a new subject, too. Edge-edge.

So, with a little tweaking (adding the subject within a generic RDF resource statement, as in example 1, or using a shortcut as in example 2), the rules are met and the knowledge can be processed.

(Check out the example RDF files with the RDF Validator to see a graphical demonstration of node-edge-node.)

Once you’ve described one data set with these rules, interferences can be made to other data sets made with the same rules.

As an example, RSS is nothing more than a quick news blurb that gets consumed in less than 24 hours and doesn’t persist. The power of RDF isn’t necessary for RSS used by aggregators, primarily because the data doesn’t persist and one thing about the search for knowledge: it does require that the bits of the knowledge stick around long enough to be discovered.

However, RSS captures a rich set of information about a specific web page or weblog posting: the author and creation date, as well as category, and possibly even links to other resources. What a pity to put this into a form that will only be thrown away.

Well, who says it has to be thrown away? We’s all bosses here, we is. If I says to keep it, I’s boss, and you listen up or Bird be real angry, she will. Real angry. Hissy fit angry.

I modified my individual weblog posting archives to include a bit of RDF in the header that contains the same information used to produce the RSS files that aggregators so callously consume and toss aside. Since this modification was in the template, this RDF is generated for each page automatically. And once persisted in the archive page, it’s there for anyone to discover, providing a richer set of data than just that assumed with keywords pulled from the text.

In this RDF is an identification of the author, an entity which is rounded out by a FOAF (Friend-of-a-Friend) RDF file; knowledge of me, who I am, adds depth and categorization to my Book Recommendation list RDF, and so on and on — a vicious cycle of knowledge acquisition.

(Archived page and comments at Wayback Machine)