- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 18 Aug 2010 15:46:10 +0200
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Ivan Herman <ivan@w3.org>, Shane P McCarron <shane@aptest.com>, martin@weborganics.co.uk, W3C RDFa WG <public-rdfa-wg@w3.org>
Mark Birbeck, Wed, 18 Aug 2010 14:00:05 +0100: > Hi Leif, > > I think @cite and @longdesc are more than just a resource waiting for > a predicate to be defined. They already have semantics about a > relationship between the current document and another, it's simply > that those semantics haven't been defined in RDF terms. It is true that they already have semantics about the relationship between (in @longdesc's case) the subject (@src) and another resource. But, for instance, in @longdesc's case, the longdesc URL doesn't need to be another _page_, it could be a fragment on the same page. Whether it is another page or another fragment, can e.g be expressed via the predicate. I don't think that @longdesc, when used inside RDFa, needs to show the exact same predicate/object relationship as a "pure" representation of the host language's built-in semantics represent. For instance, when @cite points to a (re)source, then is that source an exact copy of what appears inside the <blockquote/>? That is: do you quote - in full - a fragment from the cited (re)source? Or does the @cite attribute point to the entire work in which the quoted fragment, somewhere, is found. This should be possible to express - and refine - via a predicate that the author selects. It must be up to the author to not misuse @cite or @longdesc, from the point of view of the host language - same as for @src or @href. E.g. sometimes newspapers publishes documents online in image form. Via @longdesc, one could link to a transcript. An RDFa predicate could declare the longdesc URL to represent a transcript. Thus, I don't see why the predicate must represent the host language's purist interpretation of what the longdesc relationship is. > Similarly, @alt is more than just a plain literal waiting for a > predicate to be defined. It has the semantics of being a label for a > resource, but once again there is no precise definition for it, in RDF > terms. W.r.t. @alt, then I don't only compare it with @content but also with <element>content</element>. The <element>content</element> of an element is more than some material that is waiting to be defined via RDFa. Thus, I cannot see that you have provided a sound justification for why it is illogical to treat @alt as @content. > So, whilst one /could/ ignore the semantics of these attributes, and > treat them as the same as @resource and @content, that would be to > ignore the semantics that HTML already gives to these attributes. I don't agree that to treat @alt like @content/content is to ignore its semantics. I hold that it is the opposite way. And, above, I think I have justified why treating @longdesc and @cite as @resource/@href also isn't to step on the host language semantics. > It would be far better to say that these attributes define a > predicate/object couplet in just the same way that @typeof does. But > what I'm also saying is that this is not something that should be done > in the RDFa specification, but in the HTML/XHTML ones. * Would an IMG with @longdesc be able to contain both a @longdesc and a @typeof attribute? * Does the @typeof idea mean that the @longdesc URL *cannot* be interpreted as an object - simply by the presence of the @longdesc? Why, eventually, should one prevent that? (I asked Toby the same question.) My current understanding is that to treat @longdesc as some kind of @typeof attribute would lock the RDFa interpretation of the @longdesc URL in a not useful way - see above. -- leif halvard silli
Received on Wednesday, 18 August 2010 13:46:47 UTC