[
Lists Home |
Date Index |
Thread Index
]
>> Markup, as the name alludes to, is not about normalization
>> although from the computer's point of view, that is a
>> good thing to achieve. Should one markup only to
>> the advantage of the computer? It's an easy trap to
>> fall into.
>I'd like to believe that if you can find models (markup, DB, OO or
>otherwise) that have wide applicability (and result in advantage for
>the computer) you'll find that you have models that have a good chance
>of being being widely accepted by the humans involved. See below...
Wide applicability: that's a good metric. At the very least, it
takes the audience/listener into account. On the other hand, as
noted below, when something is widely applicable, is it semantically
strong, that is, very meaningful? (wandering off topic but maybe
there is a measure of structure (however we define that) that
can be applied to determine when a markup design is widely applicable).
>> But..... if one tries to 'fix' an organically derived model,
>> one may lose some of the meaning. So even as we
>> proseletyze good practices for structuring, we come
>> back to naming as the practice to cultivate because
>> idioms are meaningful.
>>
>> Yes? No?
>This is more a gut feeling than anything formal, but in my book if
>you "solve" the naming problem you've solved normalization and you've
>solved structure. IOW, good names categorize completely and normally.
> Good categories result in natural (well understood) relationships.
Good names result in well-understood relationships, that I concede,
but I've seen names that carry too little context and names that
carry too much. Naming standards fall apart in wide use (the meta
spec problem).
>So, back to the what's a good name permathread... I bring it back up
>because the recent discussion on CG (cg@cs.uah.edu) about "The
>corporation" and the general issues recently discussed on that list
>highlight how far we are from really having good ways to build graph
>structures that are universally agreed on even for small domains.
Granted, although I don't want to invoke that thread here because
it revealed quite quickly that polarized opinions can dominate a
naming process which is why the old "Nodes is nodes, properties
is properties. Tell me who gets to name the names so we can
get on with this" trope is recommended to markup professionals.
In other words, can we ever really separate the politics of naming
from the craft? It is very difficult to do.
>Almost forgot to answer your question: if a good organic model needs
>"fixing" then it wasn't that good in the first place; too much assumed
>knowledge. So, IOW, I'd vote no...
Interesting POV. The problem is, good for whom (see last para)?
HTML and XML demonstrate something I find fascinating: scalability
is inversely proportional to semantic load. The more it means, the
less useful it is for the greatest number. That is somewhat the
Principle of Least Power, so we have to be very careful how we
apply some principles. Things of general utility tend to be
few because one doesn't need many, so differentiation becomes
cosmetic. Thus, branding.
len
|
