Re: Last Call comments on RDFa Core

> 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.

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.

>
>> 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'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.

Again, learning from practice and deployment is a good thing.

>
> As a case in point, the xfn:friend-hyperlink property in Richard
> Cyganiak's port of XFN to RDF. This has a domain and range of
> foaf:Document.
>
> 	<alice.html> xfn:friend-page <bob.html> .
>
> With some rules-based reasoning, you can infer:
>
> 	_:a foaf:page <alice.html> ; xfn:friend _:b .
> 	_:b foaf:page <bob.html> .
>

Yes, with rule-based reasoning one could infer all sorts of things. Let's
assume we don't have any rules and we just want to add some triples to a
page. Put yourself in the shoes on your average webmaster, not a zen
master of RDF and RDFa.

>> 8) Also, I can't tell if this is allowed (again, thanks to Kavi for
>> the example):
>>
>> Let's say I have a review about a restaurant. The markup to convey the
>> relationship is:
>> <span typeof="abc:Review">
>>    <span rel="abc:itemReviewed">
>>       <span typeof="abc:Restaurant">
>>
>> Microdata and microformats both remove one layer of nested html
>> elements for this scenario. For example in microdata, it is:
>>
>> <span itemtype="site.com/Review">
>>    <span itemprop="itemReviewed" itemscope
>> itemtype="site.com/Restaurant">
>>
>> And in microformats it would be shorter still:
>> <span class="hreview">
>>    <span class="item hrestaurant">
>>
>> Can we just have in RDFa?
>>
>> <span typeof="abc:Review">
>>    <span rel="abc:itemReviewed" typeof="abc:Restaurant">
>>
>> I can't see why not, but not sure what the parsing algorithm does
>> here.
>
> That last sample parses as:
>
> 	_:node1 a abc:Review .
> 	_:node2 a abc:Restaurant ; abc:itemReviewed ?x .
>
> Where ?x is whatever's described inside that inner <span> element.
>
> Why? You can understand it easier if we swap the attributes around...
>
>     <span typeof="abc:Review">
>         <span typeof="abc:Restaurant" rel="abc:itemReviewed">
>
> But it can still be reduced to two elements in RDFa, just not the way
> you've done it:
>
>   <span typeof="abc:Review" rel="abc:itemReviewed">
>       <span typeof="abc:Restaurant">

That makes sense, although you can see why people might get that wrong. I
have to admit I find the parsing algorithm for RDFa a bit difficult, and I
like RDF.

>
> If you don't mind leaving out the rdf:type triple for the the
> restaurant, you can reduce it to just one element:
>
>   <span typeof="abc:Review" rel="abc:itemReviewed" resource="_:node1">
>
> Here's a full restaurant review in RDFa 1.1:
>
>  	<div
> 		vocab="http://example.com/review#"
> 		typeof="Review"
> 		property="text"
> 		rel="item">
> 		<a typeof="Restaurant"
> 			rel="url" href="http://example.net/"
> 			property="name"
> 			>Il Massimo Tramezzino</a> is great!
> 	</div>
>
> Two elements. It corresponds to the following six triples in Turtle:
>
> 	@prefix : <http://example.com/review#> .
> 	[] a :Review ;
> 	   :text "Il Massimo Tramezzino is great!" ;
> 	   :item _:x1 .
> 	_:x1 a :Restaurant ;
> 	   :url <http://example.net/> ;
> 	   :name "Il Massimo Tramezzino" .
>
> --
> Toby A Inkster
> <mailto:mail@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
>
>

Received on Sunday, 12 December 2010 23:13:56 UTC