Hi David,
We actually have an "importer" that can grab data out of an inline HTML
table.
http://api.simile-widgets.org/exhibit/2.2.0/scripts/data/importers/html-table-importer.js
That's been around for maybe 2 years, but it hasn't gotten much use.
That's why I'm skeptical about the idea of humans managing structured
data within HTML.
Another point of skepticism is that--I think--authors don't usually
think of their audience as being composed of progressively more capable
individuals. For example, a painter doesn't start by thinking that some
of his audience have low vision, so he must paint in really big strokes
and high contrast to make sure that they can see his work. And then he
puts in progressively finer details to engage audience with better
vision. Painters usually just start painting what they have in mind.
Similarly, "data artists" probably start out thinking something like, "I
want to show a map of news articles about epidemics" [1], rather than
thinking, "I have data about epidemics and some in my audience only have
really basic non-scripting browsers". I'm not saying that one behavior
is better than the other; I'm just describing what I think is the more
common behavior. When an exhibit starts to get more and more audience,
its author might start to think about investing efforts in
accessibility--because only then does accessibility have good ROI.
David
[1] http://epispider.org/
David Legg wrote:
> Hi David,
>
>> Thanks for the links, although ... I can't find any example
>> of what POSH looks like.
>>
>>
>
> That's because POSH is an approach and not a hard and fast standard. In
> any case it doesn't look much different to Plain Old Standard Html ;-)
>
>
>> Anyway, POSH and the likes--microformats, RDFa--should work for simple
>> cases in which the data consists of relatively unconnected items. As
>> soon as you have more than one types of items and relationships between
>> them (e.g., papers and authors), then these formats start to break down
>> because you can't flatten a graph into a tree (HTML) without duplicating
>> data or repeating data.
>>
>
> I think you're looking at it backwards. The idea is to start from a
> need to present some data to a human by way of a web page. If the
> user's browser is capable of supporting CSS then you can make the data
> look more appealing. If the user's browser supports Javascript then you
> can bring the full power of exhibit in to group or sort or selectively
> present the data.
>
> In other words you don't flatten the graph into a tree, you start with
> data encoded in HTML as a graph and build up the tree from the graph
> just as you currently do with JSON or XML.
>
>
>> Consider wanting to present 2 papers with a
>> common author
>>
>> Paper 1's title, by John Doe (University X) and Jane Smith
>> (University Y)
>> Paper 2's title, by Joe Anderson (University Z) and John Doe
>> (University X)
>>
>>
>
> You could model this in HTML somethng like this: -
>
> <h1>Papers</h1>
> <div class="paper">
> <h2>Paper Darts</h2>
> <p>A classic paper on a subject not to be missed</p>
> <p class="authors">
> <a href="#a1">John Doe</a>
> <a href="#a2">Jane Smith</a>
> </p>
> </div>
> <div class="paper">
> <h2>Riveting for pleasure</h2>
> <p class="authors">
> <a href="#a2">Jane Smith</a>
> <a href="#a3">Joe Anderson</a>
> </p>
> </div>
> ...
> <h1>Authors</h1>
> <div class="author" id="a1">
> <h2>John Doe</h2>
> <p>John is an amiable fellow who doesn't say much.</p>
> <p class="university">
> <a href="#u1">University X</a>
> </p>
> </div>
> <div class="author" id="a2">
> <h2>Jane Smith</h2>
> <p>There is nothing plain about Jane.</p>
> <p class="university">
> <a href="#u2">University Y</a>
> </p>
> </div>
> <div class="author" id="a3">
> <h2>Joe Anderson</h2>
> <p>A Riveting chap.</p>
> <p class="university">
> <a href="#u3">University Z</a>
> </p>
> </div>
> ...
> <h1>Universities</h1>
> <div class="university" id="u1">
> <h2>University X</h2>
> </div>
> <div class="university" id="u2">
> <h2>University Y</h2>
> </div>
> <div class="university" id="u3">
> <h2>University Z</h2>
> </div>
>
>
>> If you model John Doe as a first-class entity, then in POSH,
>> microformats, RDFa, you have to repeat that information about him being
>> affiliated with University X. And whenever you have copies of data, you
>> run the risk of updating one copy and forgetting about the other copies.
>>
>>
>
> I hope you can see that there is no need to duplicate data. HTML can
> reference elements just like XML can and it's all accessible from the DOM.
>
>
>> Furthermore, sometimes you actually don't want to keep your data in
>> POSH, microformats, RDFa, etc., because they are hard to write and
>> manage. You might prefer to keep your data in a Google spreadsheet
>> (which Exhibit can access), or maybe you already have your data in a
>> conventional database. Or maybe your data comes from a web service
>> (e.g., your Del.icio.us bookmarks coming from a JSON feed). Etc. etc.
>>
>>
>
> I understand your point about maintaining data in HTML could be a pain
> and that exhibit was designed to let mere users do stuff without needing
> to resort to databases or writing Java. However, I'm thinking of the
> more likely case where your data is stored in some database (or
> triplestore?) and the HTML page is generated from that automatically.
>
> Regards,
> David Legg
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"SIMILE Widgets" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/simile-widgets?hl=en
-~----------~----~----~----~------~----~------~--~---
