[RDFa] Update to RDFa Scenarios, including response to Comments

I've put together a new version of the RDFa Use Case Scenarios.

http://www.w3.org/2006/07/SWD/RDFa/scenarios/20070302/

Beyond significant changes as suggested by reviewers, this includes an
updated scientific use case (small tweak to mention NCBI's database),
and a new SKOS use case, which I've basically made up from a simple SKOS
example I found on the web. I would much appreciate any feedback or a
better SKOS example!

Since this document has changed fairly significantly, I would like to
request an additional review from members of the WG.

Here's how the various comments were addressed.

Alistair:

> 1. What is the intended function of this document?
>
> [...]
>
> I suggest that, for each use case, a fragment of HTML be presented
> without any RDFa, and the set of RDF statements that you want to be
> embedded in the fragment be presented separately.

No more RDFa in there. We went with your suggestion: HTML and RDF chunks
that are supposed to be "merged", though how that's done is not
specified in this document.

> 2. Use case 5 doesn't seem to be an RDFa use case. It is a use case 
> for transferring fragments of (any) HTML between applications. The 
> only new information it provides is that any RDF statements expressed 
> as RDFa in such an HTML fragment should be properly preserved when the 
> fragment is transferred.

The use case now specifically points out that the property we seek is to
preserve the rendered-HTML-to-RDF-triple correspondence, i.e. the
locality of the triple.

> 3. Use case 6 doesn't seem to be an RDFa use case either, because it 
> doesn't introduce any new requirements for RDFa. It just says, RDFa 
> might be used in semantic wikis.

This use case is also clarified to point out the "first-class" nature of
HTML+RDFa: it should be easily transferable from one place to another
repeatedly. This may seem like minute detail, but it's the kind of
property that differentiates RDFa from other solutions that don't enable
this kind of universal mashup-ability.

>   - Specific Comments
> 
> "chock-full" - is very culture specific language, suggest use 
> something more neutral.

Not there anymore, language cleaned up.

> "The expressed structure is closely tied to the data" - I don't know 
> what this means.

Language cleared up to be more concrete.

> "copied and pasted" - copying and pasting is maybe too specific to UI 
> style or user environment, should probably talk about transferring 
> data between applications, where "copying and pasting" is a particular 
> euphemism for doing this.

I've kept this wording in only one place, since that's really what we
want, copying and pasting of a chunk of HTML. However, in the abstract,
I've used simpler language:

"RDFa is a syntax that expresses RDF structured data in HTML. An
important goal of RDFa is to achieve this RDF embedding without
repeating existing HTML content when that content <em>is</em> the
structured data."

> "HTML chunks" - "chunks" is very informal terminology. Also title is 
> not particularly informative.

No more "chunks" :) This is now "Self-Contained HTML Fragments", which
should be more informative.



Daniels' comments:
> I have reviewed the RDFa Use Cases and have some comments. I want to 
> echo Alistair's comments below, especially in terms of the issue 
> about the function of this document. I thought the goal was not to 
> show a solution to any use case but to elicit requirements only. And 
> further, there seems to me to be much overlap in the use case in 
> terms of requirements. It would be best to only have use cases that 
> overlap little in requirements (and thus fewer use cases), so that 
> when reviewing them it's easier to spot the unique requirements.

Hopefully the new version addresses these issues well.

One point: there are *more* use cases now, though hopefully the features
of each use case are now much clearer and contribute value, rather than
just additional examples.

> I also found the example blocks of HTML/RDFa quite long and difficult 
> to spot where exactly RDFa was a good fit to the use case. I'd 
> suggest smaller HTML blocks for examples.

HTML chunks have been simplified.


Guus's comments:
> 1. The use cases by itself are convincing. 
> However, a use-case description should be driven 
> by the application need and not by technology. 
> Ideally, the term RDFa does not appear at all in 
> the document: use cases only describe the 
> (desired) behavior as seen from the outside.

The new version should address this.

> 2. I would also expect to see a list of 
> requirements that can be derived from the use 
> case. I know this is in fact a post-hoc 
> rationalization of the RDFa design, but as Parnas 
> pointed out [1] this is actually an OK thing to do 
> :-).

We haven't done this explicitly. I think the requirements begin to flow
fairly clearly from the use cases, and I'm not sure adding more text
would help, but I'm happy to hear more feedback on this front.

-Ben

Received on Friday, 2 March 2007 17:01:19 UTC