Re: Last Call comments on RDFa Core

On Dec 13, 2010, at 24:13 , Harry Halpin wrote:

>> The following is not an official WG response - just my initial thoughts.
>> 
>> On Sun, 12 Dec 2010 19:26:17 -0000 (GMT)
>> "Harry Halpin" <hhalpin@w3.org> wrote:
>> 
>>> 1) Remove any reference to @href and @src to the XHTML and HTML5
>>> documents about using RDFa. They do not really make sense in the
>>> core, as the are obviously specialized for use in making RDFa easier
>>> to use with a certain number of HTML elements, i.e. <a> and <img>.
>>> Having them in RDFa core needlessly complicates the document, and
>>> makes the parsing algorithm much more complicated. It's OK to keep
>>> them in XHTML or HTML5 profiles of RDFa for ease of hand-authoring I
>>> assume, although much of their work can just be done by use of <span>
>>> tags.
>> 
>> Removing them from the parsing algorithm in Core would make that
>> parsing algorithm unable to cope with XHTML+RDFa 1.0 as it exists in
>> the wild.
>> 
>> @href in particular is especially important, not just in HTML/XHTML
>> hosts, but also in Atom and potentially in SVG.
> 
> I'm also not sure of the value add you get out of making 2-3 kinds of
> elements for is essentially a triple with 3 components, given the fact
> that it just will add to confusion of people trying to learn RDFa.
> 
> If href is that important, then maybe replace @resource with @href or  I
> would suggest then that these additions to the parsing algorithms to deal
> with @href and @src then just be put in a specialized XHTML parsing
> algorithm and in general discouraged.
> 

First of all, both @href and @src are important for backward compatibility issues. So we should not talk about removing them, just deprecating their usage in RDFa.

On the other hand, allowing @href to be used on other elements than <a> would require a change in the (X)HTML definition. The group has tried to minimize the changes on the (X)HTML although, it is true, it does have such changes because, eg, @rel is usable on every element. The big difference is that a browser has to do some special processing on @href and @src both in term of functionality and on the user interface level. That is why using @href and @src overall would lead to major complication, ie, the need to have @resource.

The only way ahead in solving your issue would be to deprecate the usage of @href and @src for the purposes of RDFa. But then... it would force repeating code in cases when we use @href right now, ie, in an <a>

<a rel="something" href="http://a.b.c" resource="http://a.b.c">...</a>

which is equally bad.


> Similarly, cases where you want to put a @resource then in <a> tags are
> actually then better dealt with by <span> elements. Overall, the behavior
> of the parsing algorithm should be a bit more transparent to users.
> 
> 
>> 
>>> 2) Please pick either @rel or @property for marking predicates, and
>>> do not encourage the use of both.
>> 
>> Without both, how does one express this:
>> 
>> <a about="#me"
>>   rel="foaf:homepage" href="http://tobyinkster.co.uk/"
>>   property="foaf:name">Toby Inkster</a>
> 
> You could also just add an extra <span> inside the <a> and make it clear
> what the various objects to various triples are.

That is true. I think the issue around @rel and @property is the issue of duality of literals and URI references. The rest are probably details

> 
>> 
>>> Note that OGP already treats @property as something marking out URIs,
>>> not literals, i.e. from [1]:
>>> 
>>> <meta property="og:url"
>>> content="http://www.imdb.com/title/tt0117500/" /> <meta
>>> property="og:image"
>>> content="http://ia.media-imdb.com/images/rock.jpg" />
>> 
>> I don't see why everyone takes this as an indication that RDFa is too
>> complex. Personally whether OGP were being expressed in Turtle, RDF/XML
>> or some other RDF serialisation, I'd day that the value of og:url
>> should be a literal. Why? Because you're actually talking about the URI
>> itself, not about the resource identified by the URI. og:image is
>> a somewhat more questionable case, but only slightly.
> 
> A URI of an image is a URI of a information resource for that image, not a
> string because it doesn't go to some URI with a 303 or end in a hash.
> Whether it refers *really* to a resource or not is a part of metaphysics
> that most deployers will probably never care about, much less understand.
> Given that RDF fans cannot coherently explain the conventions around
> information/non-information resource to each other, I don't see why we
> should expect end-users who are say, just learning RDF to mark-up  to
> figure out.
> 

I believe Toby's point is a little bit different. For all the reasons you cite Facebook has decided to use a vocabulary whereby the objects are all literals. That is their right, and they use RDFa consistently in this sense. Ie, the RDF triples that come from Facebook will have literals in them. It is up to the consumers of the RDF content to know about the specificities of the 'og' vocabulary and do, if necessary, a conversion in RDF.

What I am saying is: I am not sure this type of automatism should be done in RDFa. RDFa is a serialization, no more and no less.


> I'm just saying feedback from Facebook and Google seems to say that having
> "property" aim to literals and "rel" aim to URIs make as much sense as,
> Kavi puts it, having male and female genders in some languages to things
> like table. It's just convention.
> 
>> 
>>> 6) Lastly, as shown by OGP, there's two distinct use-cases for
>>> vocabularies, one where one is talking about the things a web-page is
>>> about, and the other a web-page. Right now RDFa is optimized to talk
>>> about the web-page.
>> 
>> This is perhaps something better handled at the RDF layer, by designing
>> vocabularies that fit naturally with RDFa - vocabularies where the
>> most common properties take an information resource as the subject,
>> and either a literal or another information resource as the object. OGP
>> is an example of such a vocabulary, the XHTML vocabulary is another.
> 
> It seems remarkably easy to handle it at the profile layer, rather than
> demanding existing vocabularies redesign themselves around RDFa.
> 

I am not sure how you mean 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