On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
The distinction I'm accustomed to seeing made is between "semantics", the meaning of things, and "presentation", the way that meaning is wrapped in a look, to convey it to the user.
Yes, and there's a difference between basing presentation on semantics and creating a semantic class of presentation. In one case, you have presentation classes based on their presentational characteristics, and associate your semantic classes of content with those classes of presentation, and change the associations when you want to modify how a semantic class of content is presented. In the other, you define a semantic class of content as having specific presentational characteristics, which lends itself to the likelihood that you will end up defining three or four semantically-identified classes of presentation that all have roughly the same presentational characteristics, providing greater probability of violation of the DRY principle of design -- which can get messy rather quickly.
Unless I'm misunderstanding you, you're suggesting that the concept that there might be many different tags, for different categories of source material, but which we want all to render in the same fashion, is *bad*.
I admit, we're clearly off into your territory here; I almost slid out of that last curve.
While many meanings may carry the same look, the reason people suggest that the tagging should reflect the *specific* meaning in each case is so that back-end processes which might want to can distinguish.
I'm not saying we shouldn't distinguish between content semantics. I'm just questioning the decision to tie presentation characteristics directly to semantic classes of content.
If I understood brion correctly, we're not: that will be handled in the CSS.
I'm also curious as to why adatabase query (for example) would care that it's fetching a poem, as opposed to a fondue recipe: I was pretty sure we hadn't developed DBMSes that have aesthetic taste just yet.
I believe the answer to that is "ask the Semantic MediaWiki people", though I'm not sure.
But the point isn't the DBMS.
It's programs people later write to crawl the data, and do statistics on how many poems we have, etc.
Generally, we're metamorpohsing wikitext into XML. :-)
I'm not sure I agree that semantic presentation is really a great idea to implement in markup tags. Rather, it seems to be something that should be managed via properties that are attached to tags. It provides sort of a natural hierarchical inheritance model, rather than (by way of analogy) sticking every single file on your hard drive in the root directory, like the FAT12 filesystem did.
Well, as long as the tags are distinguishable, yeah, but it seems easier to do <poem> than <special type=poem>, particular in the Wikipedia milieu.
That's a good point. Tag properties may not be the best way to handle it. In fact, there's no reason that a simple tag syntax can't be used for semantic markers, and that these cannot be used as cues for applying presentation styles. What concerns me about this is that it seems the way we're implementing a tag syntax for semantic markers is by actually making the semantic markers and presentational style cues synonymous, rather than merely associated (and decoupled).
Ah. No, as I say, if I understood brion correctly, it's a CSS thing.
To further muddy the waters of the use of the term "semantic": I'm not worried about the syntax of assigning semantic markers and presentational styles. Rather, I'm considering the semantic structure of our markup, and how best it can be planned out for future maintainability. It looks to me like extensions to the semantic structure of the wiki markup are being implemented as features, when such should instead be approached as core functionality. After all, the parser is an implementation detail: the language definition is what makes the parser worth using.
Ok, I'll admit to having completely fallen off the wagon on that last graf. Could you expand?
Cheers, -- jra