[
Lists Home |
Date Index |
Thread Index
]
At 04:40 PM 6/11/2002 -0400, John Cowan wrote:
>Simon St.Laurent scripsit:
>
> > I don't believe I'd find the parts of foo to have any commonality, much
> > less "common"-ness. I guess an enumeration or a regex with lots of OR in
> > it for the content could define some, but I prefer commonality to be a
> > pattern that emerges from the information.
>
>I didn't think you would. But how about this perfectly sensible and useful
>type (which I give only in part):
>
>{14, 18, 23, 28, 34, "Times Square"} : stations-on-the-#1-subway-line
>
>These have little lexical commonality, but the underlying semantics is
>very sensible (if a tad application-specific).
Sure thing. You can put them all inside markup - element type "station"
containing element type "name" sounds good. Other element types could
identify which line the station was on, and perhaps an element type
containing these would identify them as New York City Subway. That's
typing on an appropriate level for that. No need for regex there, unless
you felt like skipping out on the markup.
> > Regular expressions are pretty good at describing a wide variety of
> lexical
> > commonalities.
>
>But they also work for things that have almost no visible commonality at
>all, so your argument proves too much!
Sure thing - but note that the rest of my message described stretching
descriptions to cover things with less and less commonality. Regular
expressions don't provide an instant limit, but their complexity (or
openness) can be a good indicator of the level of commonality. More
important, they can be used more actively to explicitly add type
information (casting in XML element types?) to information.
Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue
|
