Johan, I've finally looked at your embedded-table exhibit. Very nice
work. It certainly accomplishes the goal of presenting the data to
google. The only thing that concerns me as an author is that, as you
say, the html is not particularly self describing. So if I edit it by
hand, I am liable to make a mess of my data by, e.g., leaving out a
blank column entry where some data is missing, and thus shifting all the
values to the wrong properties. And I won't even see the problem unless
I careful read the rendered exhibit.
One way around this would be to continue using json as the authoratative
copy, but then use html table as the "presentation copy". I think this
would be a good thing to hang off the "copy all" button: suppose that to
the current list of RDF/XML, Semantic WikiText, Exhibit JSON, and
Tab-Separated Values, we added a fifth option of "HTML tables" (I use
the plural because I think that, as in your exhibit, one table per type
is desirable). I'm not sure whether it is better to output just the
tables, or to output a complete web page containing the tables. But
either way, I could continue to edit (and look at on the web) a
"staging" copy of the exhibit, and then paste my tables into a
presentation copy.
Alternately, if you wanted to make the html tables more self describing,
one could accomplish it by wrapping each value in a span tag that
specified the property that value was associated with (of course with
this approach one doesn't actually need the table at all, but it is
probably still a good choice to keep the data nicely formatted without
javascript). Unfortunately, I fear this would make the data entry so
verbose that nobody would be willing to do it.
-David
Johan Sundström wrote:
> On 2/3/07, David Huynh <[EMAIL PROTECTED]> wrote:
>
>>> The .exhibit-timelineView-timelineContainer element has the border,
>>> but playing in Firebug, it looks like this should work if it was
>>> instead put on the div classed "exhibit-timelineView-timeline
>>> timeline-container" instead. Should I file that as a feature request
>>> ticket instead of mentioning it here?
>>>
>> You can just include your own CSS rules *after* you include
>> exhibit-api.js to override Exhibit's styles. That's the "right" way :-)
>>
>
> I figured out a better way. Setting the width of the view panel to
> make room for a browse panel on the right via some javascript (for
> once there is no real point trying to do it in CSS) solved the issues
> I had with content colliding with the floated browse panel.
>
>
>> Very nice! I turned off Javascript and still saw the content--that's great!
>>
>
> There is a cute some-javascript-handled hack there too which ghosts
> all past performances and emboldens the next one, in case Exhibit
> failed to load. ;-)
>
>
>>> All that functionality probably hasn't completely stabilized yet, but
>>> some of it could use more eyes and discussion already.
>>>
>> Do you want to stabilize this before locking down Exhibit 1.0 to start
>> on 2.0? (Yeah, I know, 2.0...)
>>
>
> I think it might be in a fairly decent state already, though it would
> be useful with more prying eyes and people trying to use it, to see if
> I have just not hit all the scenarios people are likely to encounter
> and which should be possible. At the moment I've worked out all the
> bugs that bit *me*, anyway, which is always something. :-)
>
>
>> It's quite a trade-off, though. Each record, e.g.,
>>
>> <tr><td>1</td><td>2</td><td>Thingy</td><td>Stratford-Upon-Avon</td></tr>
>>
>> is less self-describing than its equivalent in JSON:
>>
>> { Property1: 1,
>> Property2: 2,
>> label: "Thingy",
>> Property4: "Stratford-Upon-Avon"
>> }
>>
>
> I never really liked HTML tables either, but the lack of context isn't
> any worse than with tab or comma separated values. HTML tables are not
> particularly well suited for text editors, though, even if it gets a
> little better formatted as my example page where a typical row looks
> like this:
>
> <tr><td>2004-09-18 kl 20</td>
> <td>San Leonardo</td>
> <td>Konsert</td>
> <td>Verbania, Italien</td></tr>
>
> ...which is almost readable, and certainly even more so in the context
> of surrounding rows. But I won't argue the point; HTML beautifully
> combines being neither very pleasant as a markup nor layouting format.
> ;-)
>
>
>>> (I havent tied in the map functionality yet, since I didn't remember
>>> how to do it at the time, so the final tab puts the Exhibit into an
>>> eternal busy state, for the time being.)
>>>
>> In the location array, replace "name" with "id". Then in the map view,
>> remove ex:start and ex:end and add ex:latlng="latlong". Hope that works!
>>
>
> I ended up taking my time remodeling relations and doing a lot more in
> the process, heavily tweaking things and messing about with the map
> view code, and am sort of happy with the updated outcome:
>
> http://ecmanaut.googlepages.com/choir-events.html
>
> The multi-hop facets (.location.Stad here, for "city") behave a little
> surprisingly; first, they don't exist at all, when the page has
> loaded. Toggle something on and off, though, and they show up.
>
> Unrelated side thought: I am starting to lean towards modeling all
> data in English, to get presentation layer issues like CSS class names
> and similar that don't violate W3C rules (I presume some browsers
> might not like unicode names there, though I honestly haven't tried
> the territory much).
>
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
