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

Hi Ben,

I have only two minor, editorial comments

- AFAIK, we agreed in Cambridge that we would *not* include RDFa code to
the document. However, Use Case #2 still includes the
property="dc:creator" in the code; it should probably be deleted

Actually I wonder whether, for the final document, it is not worth
having all those examples marked up with RDFa, store them somewhere, and
link to those from this document. For learning RDFa that might be useful
(I presume you have those somewhere, so it would not be a big deal to
have them).

- For Use Case #8, I realized the other day that the Turtle syntax for
lists[1] is *without* commas! (Maybe parsers accept the code with
commas, I must admit I do not know, but the official version for the
time being is[1] which does not use them). Should be ammended in the text...

That is all. In my view, it is a go for the document...

Thanks

Ivan


[1] http://www.dajobe.org/2004/01/turtle/#sec-examples

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
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
URL: http://www.w3.org/People/Ivan/
PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf