Comments on Use Cases draft

Ready to publish? I do think a little more work could make a lot of
difference. So perhaps the question is: will we be more motivated to
improve the doc with draft publication as a target, or in response to
feedback?

All else equal I'd say give it another week or so, but depends on what
seems best for heartbeat/24th Oct Big Bang.

General Points
==============
Overall pretty good, IMHO the problem if anything is that there's too
much material, the core use case descriptions could be tighter. It
might be worth trying a one-sentence summary of each use case (which
could be used in the contents), then trimming the descriptions of
anything a long way from that summary.

Having said that, the Introduction is thin...

XForms seems rather disproportionately represented - "Healthcare" &
"XForms-based Webapps" (or maybe I'm just behind the curve).

I think it's good to include the diagrams (ditto for Primer), though 2
of them I found not-so helpful (Wikis and e-learning; XForms-based
Webapps).

*** Contributors ***
"Danny Ayers, ???"
- I don't know whether the W3C has a convention, I usually go for
"Independent" or "Unaffiliated".

*** Introduction ***
"A number of documents contain data that could be valuable if they
were automatically accessible in different formats." - "different
formats" could be misleading, but I can't think of a simple
alternative - something that expresses "accessible to systems which
don't use that specific document format themselves (but understand
RDF)".

Sorry, the second sentence seems a bit misleading too: "In particular,
this collection of use cases illustrates how XML and XHTML documents
can be decorated with microformat, Embedded RDF or RDFa statements to
support GRDDL transformations...". Pointing to a profile doesn't
really seem like decoration to me - and is the namespace doc mechanism
still in the spec? - Invisible decoration?

*** Use case #1 - Scheduling : Jane is trying to coordinate a meeting. ***

This would make a compelling application, but I'm not sure how well it
stands in its present form as a use case, the mechanism wiring part
(e.g. GRDDL processing being applied on-demand from the query) comes
across as complex and confusing. The part from "Browsing the calendar
of her friends..." seems like a different (though no less worthwhile)
use of the data.

Perhaps it could be clearer (without losing anything) were it broken
down into smaller functional chunks, e.g. "Jane uses a GRDDL Processor
to automatically extract data from each page, and combines this RDF in
a single model. She then writes a query to filter the events down to
those dates when all four friends are in the same city..."

hCalendar - link: http://microformats.org/wiki/hcalendar

Rewording?:
"Since all four of the friends have calendars which are GRDDL source
documents and despite their different formats, GRDDL can convert all
their calendar data to RDF, which can then be queried using tools such
as the RDF query language SPARQL."
=>
"Despite their different formats, the calendars of all four friends
can be used as GRDDL source documents and converted to RDF. Once
expressed as RDF the data can be merged and queried using tools such
as the SPARQL query language."

*** Use case #2: Health Care: Querying an XML-based clinical data
using an standard ontology ***

This block comes across as relying on a special system (no offence to 4Suite) :

"He wants to use a content management system (such as 4Suite) which
includes a mechanism to automatically replicate an XML document into
equivalent, named RDF graphs for persistence in synchrony with any
changes to the document."

There's good justification in the paragraphs that follow for throwing
out their XML representation altogether and just using RDF. The
primary justification (offered by 4Suite) seems to be getting the
utility of RDF and XML tools. Perhaps the benefits of the XML side
could be reiterated?

"The expense of dual representation as plain-old XML and RDF is
space...", hmm...only if you can be sure of total synchrony, in
practice the expense of losing sync can be a nightmare...

*** Use case #3 - Aggregating data: Stephan wants a synthetic review
before buying a guitar. ***

I'm blind to the faults on this one, although this now seems clunky:
"and autodiscovered FOAF profiles possibly gathered by a scutter from
Stephan's own profile...", maybe drop the scutter explanation and
reword to something like "and autodiscovered FOAF profiles possibly
harvested through links in Stephan's own profile...".

*** Use case #4 - Querying sites and digital libraries: DC4Plus Corp.
wants to automate the publication of its electronic documents. ***

"She is concerned by the heterogeneity and distribution of all these
electronic documents produced."  - it's not really clear what the
problem actually is (is homogenization and centralization the
solution?)

"Then a GRDDL Processor extracts this metadata in RDF." => "A GRDDL
Processor extracts this metadata as RDF."?

*** Use case #5 - Wikis and e-learning: The Technical University of
Marcilly decided to use wikis to foster knowledge exchanges between
lecturers and students. ***

Link to definition of "Wiki" probably a good idea.

There's a lot of material before we get to "Let us consider the case
of Michel..." - is so much background needed? (Perhaps move out to
longer version associated with demo implementation..?) Similarly the
last set of bullet points seem peripheral to the core use case
(although all reasonable points in their own right).

*** Use case #6 - XForms-based Webapps: Tom wants to extract transport
semantics from an online form used to edit blog entries. ***

Tom becomes Voltaire...

"...every site he should federate with." - better word than "federate"
(it's not clear what's intended until a few lines down).

I don't understand the diagram here.

s/URLs/URIs

"without the necessity of a top-heavy web service stack" sounds
derogatory, better to cut/reword.

s/deterent/deterrent

I've heard reservations of the use of "endpoint" - ok here?

*** Use case #7 - XML Schema specifying a transformation: the OAI
would like to be able to specify document licenses in their XML
schema. ***

s/XML schema/XML Schema  (I think)

Hmm, it *does* need a description of the technical solution - how far
off are we having one?

There are a few other terms that should probably go in the glossary :
microformats, RDFa, SPARQL...(I'll see if I have time ;-)

Cheers,
Danny.



















-- 

http://dannyayers.com

Received on Wednesday, 20 September 2006 20:46:13 UTC