- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 9 Jan 2013 13:39:32 +0000
- To: public-openannotation <public-openannotation@w3.org>
> 7. The specification re-uses the cnt and trig namespaces. But these are not stable proposals, I fear. > Is anyone still working on the CNT working draft? What will be the status of TriG after the RDF Working Group publishes new material for Named Graphs? I emailed the Shadi Abou-Zahra from the Evaluation and Repair Tools Working Group (ERT WG) [2] , who conforms that the Content in RDF [3] is a stable proposal with only a few minor outstanding issues, but is not currently on the REC track as they are focusing on doing this for their main specification EARL [1]. They welcome any comments on the specifications. I've let him know that we would consider it useful to have Content-in-RDF on the REC track as well. Their WG has also developed the HTTP in RDF working draft [1] which I think could be useful for us to specify HTTP accept headers etc slightly structured, rather than the current opaque rdf:value blurb in oa:HttpRequestState. For reference, you may find extracts from our email exchange below. [0] http://www.w3.org/TR/EARL10-Schema/ [1] http://www.w3.org/TR/HTTP-in-RDF10/ [2] http://www.w3.org/WAI/ER/ [3] http://www.w3.org/TR/Content-in-RDF10/ On Tue, Jan 8, 2013 at 11:02 PM, Shadi Abou-Zahra <shadi@w3.org> wrote: > (..) > Content-in-RDF is mostly up-to-date, we only received a few comments most of > which are resolved and that can be addressed quite quickly: > - <http://www.w3.org/WAI/ER/Content/issues> > (..) On Wed, Jan 9, 2013 at 9:25 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote: > (..) > In our view it would be very desirable to have ContentInRDF on the REC > track, as it is a very useful vocabulary in many contexts, independent of > the EARL work, which is a bit more orthogonal to our annotations work. > (..) On Wed, Jan 9, 2013 at 8:44 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote: > Thanks for the update. > No, it was just a general concern from some of our members in referring to a > working draft that at first glance could seem abandoned. Content in RDF fits > our needs quite nicely to allow inline annotation bodies, and we attach also > dc:format to describe mime type, and type it using DCMI typed to in a more > abstract way know if it is text, image, etc. > (..) On Wed, Jan 9, 2013 at 8:54 AM, Shadi Abou-Zahra <shadi@w3.org> wrote: > I can see your concern, we have been kind of stuck with the test suites > development that is blocking progress of the entire EARL suite. But I > confirm that this is not abandoned work and that, according to the list of > issues I previously sent you, Content-in-RDF seems fairly stable. > > Aside, there were comments requesting Content-in-RDF and other support notes > for EARL to become REC-track documents. This would make them more stable but > would need much more effort for documenting test suites and implementations > to finalize. The current group decision is not to make that move, so we > could consider finalizing these support notes as only the EARL 1.0 Schema > document itself is on REC-track. Thoughts on this? On Wed, Jan 9, 2013 at 9:25 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote: > Thanks for your reply. > In our view it would be very desirable to have ContentInRDF on the REC > track, as it is a very useful vocabulary in many contexts, independent of > the EARL work, which is a bit more orthogonal to our annotations work. > > We are probably also interested in the HTTP in RDF vocabulary as we annotate > specific resources with Accept headers, etc, but don't want to go to > verbose, perhaps limit ourselves to http:fieldName and http:fieldValue. On Wed, Jan 9, 2013 at 12:34 PM, Shadi Abou-Zahra <shadi@w3.org> wrote: > (..) > As said, ERT WG took a provisional step not to take these documents to > REC-track as they are really only supporting documents ("extensions") for > the core EARL vocabulary. This is primarily due to the fact that currently > not very many web accessibility evaluation tools, which is our main focus of > work, support the extensions and we would have even more difficulty finding > and documenting test suites and implementations. > > Having said that, over time we have been seeing increased uptake of these > vocabulary extensions outside our direct area of work. If there is > sufficient use, especially readily available test suites and tool > implementations, then it may change the current position of ERT WG. > > This is obviously my perspective that would need ERT WG discussion. > (..)
Received on Wednesday, 9 January 2013 13:40:20 UTC