Re: Comments on Use Cases draft

Thanks for the detailed edit.  A few comments / responses inline below:

On Wed, 20 Sep 2006, Danny Ayers wrote:
> 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.

Not a bad idea.  I think it would help making them more compact.

> Having said that, the Introduction is thin...
>
> XForms seems rather disproportionately represented - "Healthcare" &
> "XForms-based Webapps" (or maybe I'm just behind the curve).

Hmm.. The healthcare usecase doesn't gain much by assuming XForms is how 
the XML content is edited - it could simply have said a Java application 
which edits the XML content remotely.  However, the reality is that XForms 
*is* completely geared for distributed editing of XML content - the one 
thing both those usecases have in common.  So, I don't know.

> *** 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?

Yes, the namespace doc mechanism is (http://www.w3.org/2004/01/rdxh/spec#ns-bind).

> *** Use case #1 - Scheduling : Jane is trying to coordinate a meeting. ***
> 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..."

+1

I think this might apply in other places where the GRDDL mechanism aren't 
so clear.

> *** 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?

How about (right after .. being able to query both as XML and as RDF):

The corresponding XML documents can be transformed into 'other' non-RDF 
formats, evaluated by XPath & XPointer expressions, cross-linked by XLink 
or XInclude, and structurally validated by RELAX NG (or XML Schema).

> "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...

Right, but (as you point out) this usecase depends on a content management 
system that manages this synchrony completely.  The general plug is for 
using GRDDL-type mechanisms for content management systems, but I don't 
know of any others that do, hence the explicit (and perhaps gratuitous?) reference.

> *** 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).

In addition:

"The embedded RDF is extracted using a GRDDL Processor using GRDDL 
transformations .." -> "The embedded RDF is extracted by a GRDDL 
Processor using GRDDL transformations .."

> *** 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).

'.. that he doesn't want to surf the net to find sites he might want 
to subscribe to ..'? or 'he might want to syndicate'

> I don't understand the diagram here.

The mechanism is pretty involved here, I can take a crack at another 
diagram.

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

+1

> s/deterent/deterrent
>
> I've heard reservations of the use of "endpoint" - ok here?

Remote service locations?

> *** 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?

I think we do have one, it just wasn't clear.  See my previous light-bulb 
moment about how this is meant to work.  Basically: the XML schema is 
served from the namespace location, the XML schema is a GRDDL source 
document which includes descriptions associating a GRDDL transform with 
its instances.  So, the XML schema serves a dual purpose for its 
instances: validation and identifying transforms to glean meaning

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

+1 
>
> Cheers,
> Danny.


Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
ogbujic@ccf.org

Received on Thursday, 21 September 2006 03:29:17 UTC