Review of Use-Case Document

Everyone,
    Since it's the duty of every member of the working group to make
sure our publications are of the highest quality and readable, please do
take the spare time read through Editor's Drafts as they are produced.
However - all these comments are only comments, and it's up to the
editor's discretion what to include or not.
   Here's my current review of the Use-Case document. Overall, great
work  - I'm very pleased we've got some simple use-cases as well as
cutting-edge ones (wiki, Xforms) - in addition to  outreach to user
communities like e-learning and health care. In general, I'm going to
add that the use-cases don't have to be fully coded, but if they are
related to projects of yours or projects you're working on, you can add
a link in the text/bibliography. So even if a use case isn't in the
primer, if we get the code or a more detailed tutorial working for a
use-case (or even an academic publication), the user can find more info.
    Second, we should remember to prune and re-order the use-case
document a bit. I think ordering the use-cases from easiest to more
challenging is probably the way to go. So, my revised order would be 1.
scheduling 2. clinical data 3. buying a guitar 4. digital libraries/W3C,
and then the wiki and Xforms cases in some order, with the "live
bookmarks" case being dropped unless further developed, the structured
query  catalog use-case being dropped (since it's kinda close to buying
a guitar), and the meeting extraction use case being put at the end
until BenA gets back.
    I'll skip scheduling, and go to the Wiki use-case. It sounds great,
yet what I would like to hear would be how a particular human teacher at
the Univ. of Marcilly is going to use this semantic wiki and GRDDL to
solve a concrete problem that previous XML/HTML technologies w/o RDF
couldn't let them do.  It seems that the problem  that Franck faced
earlier in the e-learning use case would be one way.
    Let's say Franck is teaching a course on a concrete topic like
linear algebra or history and wants to dynamically generate his course
materials. He wants to allow his students to comment and add to his
slides and papers, as well  as post new links to relevant subject
materials, so he wants to use a Wiki as well. So, let's say he's
teaching a course on French History. If various slides and papers are
marked up with time-spans, he could dynamically put together a page on
French history on the French Revolution. He could do this by specifying
"France" and "Years 1789-1799". But maybe he wants to teach a class on
revolutions in general, so he wants to include   "USA" and "1775-1776" 
in his keywords. Or he wants to see what interesting things were
happening in France during the American revoluion, so he could use
"France" and "1775-1776". Or perhaps he wants to move up the class
hierarchy and look at all "Europe" materials from "1775-1776". He might
also want to use RDF to distinguish between his authoriative (perhaps
uneditable) work and the comments and links his students add. Just an
idea on a concrete example of how using RDF to dynamically restructure
wiki data can produce better e-learning pages.
    I'm a bit less comfortable trying to provide more motivating padding
for the XForms Atom example, because I've never made an XForms app,
although I have used them and they're very cool. So, I'm a bit confused
- it seems like what the use-case is that Voltaire (great name!) is
using this XForms/Atom combo to automatically update their blog with the
content of publishers with similar interest. So, let's say Voltaire has
a blog about bird-watching. However, he's busy watching birds and
doesn't have time to surf the net and find feeds of his friends as he
looks for kites, a type of bird. The professional ornithologist Johan
Bos, who recently spotted a red kite (Milvus milvus) far from their
breeding ground in central Wales, and who recently posted a blog entry
about it. However, (is this what RDF Forms in combo with the
Intropsection document do - I'm not really seeing how this is
possible...) when Johan updates his web-log about the red kite, it
automatically gets posted to Voltaire's blog. Is this correct?
Hmmm...why shouldn't Voltaire just subscribe to Johan's blog feed, using
just normal XML? Is it the posting operation? A bit confused.
    As for the guitar use-case, I'll leave this in Brian Suda's hands -
but it would be *great* if we had a real-live microformat hReview
database to make this work, instead of having to imagine one. And then,
as Danny Ayers said, we have to "pretend" they authorized the use of
GRDDL on their data.
    With the W3C Use-case - I'm a bit unsure how normal people could see
the value of this unless it's emphasized the RDF is turned *back* into
HTML after rule-processing using XSLT. Otherwise, it appears that we've
just made a bunch of RDF from our tech reports - and unless you're an
RDF fanatic, you won't really care. It's the conversion back to HTML
after customized processing that makes this use-case work for normal
users, librarians, etc.
    For the use-case involving clinical data, again - I'd like to see
some more concrete details. Not tech details in abstract, but how a 
human facing a concrete problem would use the technology to solve it.
Let's say Kayode (which competes with the University of Marcilly for a
cool name) wants to query the data. What does the RDF buy him that
querying using Xquery doesn't? Is the same information (like diagnosis
type) spread out through multiple places in XML files that use differing
schemas, so that no single XPath expression can be guaranteed to get all
the diagnosis types? Are their differing XML files? In which case, then
mapping to a unified ontology (like the one you said was Helen Chen from
Agfa was developing - could you add a reference to this ontology?) would
make sense, and this mapping could be done via GRDDL. Then, he could
query the clinical data. I'm also going to note this is the XML-version
of the HTML guitar-buying use case.

    Hope this helps,

           cheers,
                 harry
   
   
  


    



-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Thursday, 24 August 2006 16:59:44 UTC