Re: Some concerns about the list implementation in RDFa 1.1

On Sep 15, 2011, at 12:50 , Niklas Lindström wrote:

> Jeni, all,
> 
> during the last telecon I raised some questions regarding the current suggestion of using @member for lists in RDFa 1.1.
> 
> 1. I wonder whether "member" is an appropriate name for the attribute triggering list processing. My concern is that it may not fully convey the specific list nature of the feature (since "member" conceptually also applies to the default "set" nature). I'd suggest e.g. "listitem" or "inlist".
> 

I agree that @member is not good. I think you suggested @onlist last time, and I actually like that one...


> 2. Another concern is about backwards compatibility. If @member is not interpreted by a processor, it would instead add triples the "normal" way – i.e. produce different data. This may be bad, or it may be viewed as "at least you get something". We should evaluate that.
> 

I would be in favour of the latter. Ie, yes, you get something and that is it. In most of the case what you will get is, instead of 

dc:creator (<a> <b> <c>) .

dc:creator <a>, <b>, <c> .

and I think we can live with that.

> 3. I'm also slightly uncomfortable with the use of an "empty" attribute (unless I'm "thinking in HTML5"). We briefly discussed the possibility of combining @rel/@property with @member, making the usage more compact (and solving the backcompat issue). There are some problems with that though. One concern was about what should happen if a combined attribute is present *alongside* a @rel or @property. Another was that it wouldn't follow the way RDFa currently works if such a combined attribute we're to work with references if @href/@resource is present and otherwise with literals. (Although there has been talk about the relative merit of letting @property work like that, we have not done this yet, and may decide not to. *If* we were to do that, it might be valuable to have @member work similarly.) I have not been able to come up with another solid solution to these things though, so unless others also have concerns with the empty form, I won't object further.
> 

I have thought of that again but I am really afraid of the confusion it my create with other solutions, ie, I would really prefer to keep with Gregg's model...

And, of course, in HTML5 a value-less @onlist is perfectly fine...


> (I can even imagine that @member could default to list processing, but if given a value of "seq", "bag" or "alt" it could trigger support for those containers instead. I'm not particularly in favor of that personally, but the option should be considered.)

That would be very confusing...

Ivan


> 
> Best regards,
> Niklas


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Thursday, 15 September 2011 11:18:45 UTC