- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 24 Aug 2011 09:17:05 +0200
- To: Niklas Lindström <lindstream@gmail.com>
- Cc: public-rdfa-wg <public-rdfa-wg@w3.org>
On Aug 24, 2011, at 01:27 , Niklas Lindström wrote: > >> Before going into the alternatives, I would also like to know what your problems are with [1]. I understand there are may be problems (surely there are), but you do not really touch that in your mail below. I still look at [1] as a viable alternative. See also my remarks at the end. > > I'm sorry, I should of course have discussed that as well. No problems. [snip] > >> So something like >> >> <span rel="dc:creator" resource="::Seq"> >> <span property="::member">Grigoris Antoniou</span> and >> <span property="::member">Frank van Harmelen</span> >> </span> >> >> could be replaced by something like >> >> <span rel="dc:creator" container="sequence"> >> <span member>Grigoris Antoniou</span> and >> <span member>Frank van Harmelen</span> >> </span> >> >> <span rel="dc:creator" resource="::List"> >> <span property="::member">Grigoris Antoniou</span> and >> <span property="::member">Frank van Harmelen</span> >> </span> >> >> <span rel="dc:creator" container="list"> >> <span member>Grigoris Antoniou</span> and >> <span member>Frank van Harmelen</span> >> </span> > > Interesting. First though, as said, I think containers are legacy, and > can be expressed with existing syntax and terms: > > <span rel="dc:creator"> > <span typeof="rdf:Seq"><!-- or the suggested @resourcetype > beside @rel to avoid this span.. --> > <span property="rdf:_1">Grigoris Antoniou</span> and > <span property="rdf:_2">Frank van Harmelen</span> > </span> > </span> > > It's not very beautiful, but then again, neither are containers IMO. > They are "crude" on the semantic (abstract syntax) level of RDF. I agree with that. Let me put it this way: if we succeed in finding a syntax whereby containers can also fit easily, then we should put it there. If not, we can simply drop it. It should not influence our design decision. (That being said, although I do not particularly like sequences either, they are used, though not in RDFa. For example, _any_ jpg file that has gone through photoshop, or, in many case, coming out of particular cameras, carry RDF information using Adobe's XMP which has Seq and Alt in them...) > > Furthermore, "container" is the name for Seq, Bag and Alt -- their > base class is rdfs:Container -- so I would advice against that name > for the attribute. You are right. > The RDF list structure OTOH is constructed using > the collection vocabulary [4], so I'd suggest @collection, for lists > alone. Well... for the sake of this discussion I am happy with @collection. If the design could work to include containers painlessly, then maybe a neutral term could be found. But let us go with @collection for now. > > Therefore, we might perhaps combine @container and @rel, like: > > <span collection="dc:creator"> > <span member>Grigoris Antoniou</span> and > <span member>Frank van Harmelen</span> > </span> I think that would kill the possibility of reusing hanging rels. If we use @collection only, then a construction of the form <div ... rel="p:q"> <div collection> ..... </div> <div collection> ..... </div> </div> is possible. If we merge the two, this goes down the drain... [snip] > > In fact, we might not need @member to capture literals. Scanning for > literals in list mode could be "greedy", by having it start "consume" > on the first non-whitespace text node it encounters within each > (direct) child element. > > Full example of a thoroughly mixed type list: > > <ul collection="ex:stuff"> > <li lang="en">An item</li> > <li datatype="xsd:boolean">true</li> > <li><a href="/item/three" property="rdfs:label">Three</a></li> > </ul> This type of automatism, though nice, may not work. - what if I do _not_ want a specific child to generate a list element? - what if I want to enclose a specific child element into, say, an extra span for the purpose of styling? Ie, I'd prefer to keep it very explicit. [snip] > > Of course, I can see that the "greedy" part could be considered too > powerful, and perhaps mixing in the hanging rel power will be too > implicit. So @member might be more obvious for capturing at least > literals, or them all.. That'll leave us with: > > <ul collection="ex:stuff"> > <li member lang="en">An item</li> > <li member datatype="xsd:boolean">true</li> > <li><a member href="/item/three" property="rdfs:label">Three</a></li> > </ul> > > (That being member="" in XHTML..). That's very close to your suggestion. > > Yes. The only modification I would make is: <ul rel="ex:stuff" collection> <li member lang="en">An item</li> <li member datatype="xsd:boolean">true</li> <li><a member href="/item/three" property="rdfs:label">Three</a></li> </ul> We still have to work out _precisely_ how the behaviour of these attributes work out in relation to other RDFa attributes. To be honest, my goal would be to provide some sort of a (conceptual) transformation of the DOM tree into a list-less RDFa. If this was possible cleanly, then this would mean no modification of the core RDFa processing, which is already complicated enough... If the WG agrees with the general direction, then we may want to work on that. Ivan ---- 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 Wednesday, 24 August 2011 07:14:54 UTC