- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 29 Aug 2013 15:30:59 -0400
- To: public-rdf-wg@w3.org
- Message-ID: <521FA173.9030608@openlinksw.com>
On 8/29/13 2:17 PM, Gregg Kellogg wrote: > On Aug 29, 2013, at 8:19 AM, Kingsley Idehen <kidehen@openlinksw.com > <mailto:kidehen@openlinksw.com>> wrote: > >> On 8/29/13 10:50 AM, Gregg Kellogg wrote: >>> On Aug 29, 2013, at 6:14 AM, Kingsley Idehen <kidehen@openlinksw.com >>> <mailto:kidehen@openlinksw.com>> wrote: >>> >>>> On 8/28/13 8:12 PM, Gregg Kellogg wrote: >>>>> I've integrated the last EARL report for Turtle [1]. Note, that as >>>>> it uses ReSpec, it can be saved out and frozen too. >>>>> >>>>> The report shows 10 fully conforming implementations. >>>>> >>>>> Gregg Kellogg >>>>> gregg@greggkellogg.net <mailto:gregg@greggkellogg.net> >>>>> >>>>> [1] >>>>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/index.html >>>>> >>>>> >>>>> >>>>> >>>> Gregg, >>>> >>>> Shouldn't the Turtle documents associated with each test suite >>>> submission be discoverable from these documents? Basically, their >>>> URLs should be referenced from this document etc.. >>> >>> Each input file used to generate the report is listed in appendix B >>> [1]. How would you suggest marking this up to make it more machine >>> readable? >>> >>> Gregg >>> >>> [1] >>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/index.html#individual-test-results >>> >> >> Currently, a user agent would end up with something that looks like >> the typical URIBurner page that describes a Web Document [1]. If you >> add <link/> based relations (e.g., rel="related" since "related" is >> IANA registered and maps to xhv:related) in the <head/> section of >> the HTML document, we end up with better description pages due to the >> fact that the "xhv:related" relations will be much more visible and >> comprehensible to both humans and machines :-) > > There are two different kinds of referenced files, alternative > versions of the EARL rollup (earl.jsonld and earl.ttl) and the source > files used to generate the report. For the former, I think that > xhv:alternate is most appropriate. For the latter, I agree with > xhv:related. Yes, of course. > I've updated the repot (adding Jose Labra's recent submission) adding > appropriate relations to both the <a> references, and <link> headers; > this is redundant for RDFa, but might be useful for FeedBurner. FeedBurner or URIBurner ? :-) > > Also, note that "related" is not a term defined in an XHTML:RDFa > initial context (although "alternate" is), in any case, the report is > HTML5, which doesn't define any link relations; best is to add both > "alternate" and 'xhv:alternate" along with "related" and > 'xhv:related", the un-prefixed versions in the head section using > <link>, the prefixed versions in the body. We map "related" to xhv:related. Anyway, you can also use URIs for relations that aren't in IANA e.g., <http://www.w3.org/2000/01/rdf-schema#seeAlso> . > > Re-looking at your uriburner, I do see the xhv:alternate showing up, > but not the xhv:related. Let me know if there are other changes you > thing would be useful. I'll take a look. Kingsley > > Gregg > >> [1] >> http://linkeddata.uriburner.com/about/html/https/dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/index.html#individual-test-results >> . >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web:http://www.openlinksw.com >> Personal Weblog:http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca <http://Identi.ca> handle: @kidehen >> Google+ Profile:https://plus.google.com/112399767740508618350/about >> LinkedIn Profile:http://www.linkedin.com/in/kidehen >> >> >> >> > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 29 August 2013 19:31:25 UTC