W3C home > Mailing lists > Public > public-html-data-tf@w3.org > November 2011

Re: Guidance on publishing in multiple formats

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Wed, 9 Nov 2011 14:10:26 -0500
To: Jeni Tennison <jeni@jenitennison.com>
CC: HTML Data Task Force WG <public-html-data-tf@w3.org>
Message-ID: <500968DF-D9F8-4731-BA53-B05C048FABD4@greggkellogg.net>
On Nov 9, 2011, at 10:52 AM, Jeni Tennison wrote:

> Gregg,
> On 9 Nov 2011, at 03:15, Gregg Kellogg wrote:
>> Looks really good Jeni. One small comment in the examples: you use both <meta> elements with datesTime values. now that <time> seems to be back, these would more naturally be expressed using the <time> element, which would also preserve the literal dataType:
>> <time itemprop="dtstart" property="startDate" datetime="2016-04-21T20:00:00" content="2016-04-21T20:00:00" datatype="xsd:dateTime/>
> Yes. I was lazy and copied the example directly from the schema.org documentation. The way microdata *was* specified, it would have been invalid to use the <meta> element there. I don't know whether, when the change from <time> to <data> is reverted, the restriction on how date/times are specified will be re-introduced or not.
>> One of the proposed changes for HTML+RDFa is to process @datetime in a similar manner to microdata, so the @content and @datatype attributes could be removed. It hasn't come up for a vote yet, but it seems non-controversial.
> Yep, that will make it much better. That's rdfa-ISSUE-97 isn't it? [1]

Yes, but it's also wrapped up in other proposed changes for @property, including using @data as an object attribute and use of <meta> and <link> in body content.

>> Also, there is a proposal in RDFa to give @property many of the same attributes as @rel, which would also allow the markup to be reduced. Presuming we vote for this on Thursday, elements could be simplified further:
>> <div class="location" itemprop="location" property="location" typeof="http://schema.org/Place>
>>   <a property="url" href="wells-fargo-center.html">
>>       Wells Fargo Center
>>   </a>
>>   <div property="address" typeof="http://schema.org/PostalAddress">
>>     <span property="http://schema.org/addressLocality">Philadelphia</span>,
>>     <span property="http://schema.org/addressRegion">PA</span>
>>   </div>
>> </div>
>> Note how @typeof now bonds to the object, rather than the subject. This is also true if you continue to use @rel.
> I know that you've been proposing changes about this and I was hoping that they would help with this example, including the rather gnarly issue about chaining due to the nested @href. Is there a publicly available test implementation of the changes?

I haven't updated my distiller yet, but if you're up to installing the Ruby gem [2] yourself, it's fully implemented:

	gem install linkeddata
	git pull git://github.com/gkellogg/rdf-rdfa.git
	rdf-rdfa/script/parse --format ttl http://your-example-goes-here # or from stdin


>> Also, unless @vocab is used, @property values must be be spelled out using CURIEs or IRIs. In this sense, the Mixing Syntaxes example is currently incorrect.
> The top-most div had a @vocab on it:
> <div class="vevent"
>  itemscope itemtype="http://microformats.org/profile/hcalendar#vevent"
>  about="_:event" vocab="http://schema.org/" typeof="Event">
>  ...
> </div>
> but it was confusing because the nested @typeof attributes used full IRIs. I've changed this to specify @vocab wherever there's a @typeof.
> I'm tempted to change it to use the schema: prefix throughout since this is more reliable than using @vocab (less likely to get lost through copy/pasting) as per the guidance earlier in that page.
>> @itemprop + @itemscope becomre more like @property + @href/@src/@resource and @typeof. Note that without @typeof (even an empty value), @property will not cause chaining in the proposed changes to RDFa 1.1.
> Great :)
> Jeni
> [1] http://www.w3.org/2010/02/rdfa/track/issues/97
[2] http://github.com/gkellogg/rdf-rdfa

> -- 
> Jeni Tennison
> http://www.jenitennison.com
Received on Wednesday, 9 November 2011 19:11:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:25 UTC