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

Ben,

Thanks for the update. I think the document, with 
the amendments posted on this list, is worth 
publishing. I have one remark, but I consider it 
your editorial discretion whether you do with it:

   I suggest to include a bit more technical 
detail on why Micro Formats don't work well for 
some of the use cases, possibly through a more 
detailed MF scenario for one use case. This would 
make the argument stronger.

Guus

Ben Adida wrote:
> 
> 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
> 

-- 
Vrije Universiteit Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
T: +31 20 598 7739/7718; F: +31 84 712 1446
Home page: http://www.cs.vu.nl/~guus/

Received on Tuesday, 6 March 2007 08:22:20 UTC