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

Re: Microdata implied property order

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Thu, 20 Oct 2011 15:31:25 -0400
To: Bob Ferris <zazi@smiy.org>
CC: "public-html-data-tf@w3.org" <public-html-data-tf@w3.org>
Message-ID: <D6B2E6EB-E3DA-46C6-8E19-4F4432273EF4@greggkellogg.net>
On Oct 20, 2011, at 1:44 AM, Bob Ferris wrote:

> Hi,
> 
> [snip]
> 
>>> For example (from schema.org):
>>> 
>>> <div itemscope itemtype="http://schema.org/MusicPlaylist">
>>> 1. <div itemprop="tracks" itemscape
>> itemtype="http://schema.org/MusicRecording">...</div>
>>> 2. <div itemprop="tracks" itemscape
>> itemtype="http://schema.org/MusicRecording">...</div>
>>> </div>
>> 
>> s/itemscape/itemscope/
>> 
>>> There is an assumed ordering of the tracks in a playlist, but no
>> clear processing rules (for RDF anyway) to describe the ordering. With
>> previously existing rules, this would render the following:
>>> 
>>> @prefix : <http://schema.org/> .
>>> [ a :MusicPlaylist
>>> :tracks [ a :MusicRecording; ...], [a :MusicRecording; ...]
>>> ]
>> 
>> Yes. I think it should be:
>> 
>> @prefix : <http://schema.org/> .
>> [ a :MusicPlaylist ;
>> :tracks (
>> [ a :MusicRecording; ...]
>> [ a :MusicRecording; ...]
>> ) ;
>> ]
>> 
>>> RDFa recently added the @inlist attribute to indicate that property
>> values should be added to a list, so the same thing could be represented
>> as follows:
>>> 
>>> <div vocab="http://schema.org/" typeof="MusicPlaylist">
>>> <div rel="tracks" inlist>
>>> 1. <div typeof="MusicRecording">...</div>
>>> 2. <div typeof="MusicRecording">...</div>
>>> </div>
>>> </div>
>> 
>> Or:
>> 
>> <div vocab="http://schema.org/" typeof="MusicPlaylist">
>> 1. <div rel="tracks" inlist><div typeof="MusicRecording">...</div></div>
>> 2. <div rel="tracks" inlist><div typeof="MusicRecording">...</div></div>
>> </div>
>> </div>
>> 
>> where the parallels with the microdata equivalent are a little more
>> obvious.
>> 
>>> which would render the following:
>>> 
>>> @prefix : <http://schema.org/> .
>>> [ a :MusicPlaylist
>>> :tracks ([ a :MusicRecording; ...] [a :MusicRecording; ...])
>>> ]
> 
> For representing ordered lists in RDF, I co-designed some time ago the 
> Ordered List Ontology [1], which enables a utilisation of existing items 
> (resources), as it is the case in the music playlist example above, by 
> not including position information into the item object (i.e. there are 
> separate slot objects that enclose the item objects).
> For addressing the music playlist, one could then utilise a 
> specialisation of the ordered list concept, which is called 'playlist' 
> [2]. To get an impression how such an example looks like, please have a 
> look at [3].
> I guess, one can adapt the ordered list concept to microdata and RDFa as 
> well (incl. some inbuilt mechanism to simplify the mark-up).
> 
> Cheers,

Thanks Bob, I've used the Ordered List Ontology before, and recommended it as a best practice; thanks for creating that. The whole issue of collections and containers is getting a lot of discussion in the RDF WG right now, and no one seems entirely satisfied with either. However, Collections (RDF:List) seems to be the preferred choice at the moment.

At one time, I had suggested that the RDF WG consider something like the Ordered List Onotology as a better replacement for both Collections and Containers, but it does add a number of things that probably don't make it appropriate for direct syntactic support. For example, to add a track number requires asserting a property against the link element.

Within the context of this TF, we're mostly concerned with the proper representation of the Microdata syntactic elements, including whether or not to honor the implied ordering multiple itemprop values as well as the items within the document themselves.

With regards to improving the schema.org playlist representation, you might consider bringing this topic up in public-vocabs@w3.org. In the Connected Media Experience (when it was RDF), we used a variation of the Ordered List Ontology for describing album tracks and playlists. The added HTML markup to represent them, while expressive, was considered to be something of a burden, unfortunately.

Gregg

> Bo
> 
> 
> PS: rdf:Lists are not really appropriated, because we not intend to 
> modell a music playlist with a list of lists of lists (what's the case 
> of the rdf:List recursion)
> 
> 
> [1] http://purl.org/ontology/olo/core#
> [2] http://purl.org/ontology/pbo/core#Playlist
> [3] http://purl.org/ontology/pbo/playbackontology.html#sec-playlist-example
> 
Received on Thursday, 20 October 2011 19:32:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 October 2011 19:32:40 GMT