Re: Last Call comments on RDFa Core

Harry, just some questions/comments on your comments (non exhaustive, there might be more coming...). This is NOT a Working Group answer just my own musings.

On Dec 12, 2010, at 20:26 , Harry Halpin wrote:

[snip]

> 
> Here's the comments:
> 
> 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.
> 

The issue we were having is that the @href/@src attributes do come back then in the XHMTL and HTML5 documents anyway while, you are right, they are not really relevant in Core. We also envisage that the RDFa+SOMELANGUAGE would come out fairly often (Toby was already looking into an RDFa+ATOM possibility). The question is what are the 'changes' that a particular host language can provide. We tried to keep away from the possibility of a host language introducing new attributes and hence a direct change in the processing steps because it would then become fairly difficult for implementations to follow. Alternatively, we would have to come up with some official formalism on introducing new attributes on a host language level. We were not sure (and I am still not sure) it is worth doing that for two attributes that clearly have a historical nature and importance in the main deployment target...

But it may be worthwhile think again.

> 2) Please pick either @rel or @property for marking predicates, and do not
> encourage the use of both. This comment comes from Kavi Goel I imagine the
> use of both was caused by obscure features of HTML like the diff between
> <link>, <meta> and desire to stay XHTML compliant with <a>. These are no
> longer design goals, as now RDFa is just adding new attributes anyways.
> Based on feedback from Google RichSnippets, people get these two confused
> constantly. The supposed reason for keeping them apart is that @rel is
> supposed to point to URIs while @property points to literals. However, why
> not just use a simple EBNF for URI/IRIs to parse the object and *then* use
> that to determine if it's a URI or not? In the pathological edge-case
> where someone wants a URI to be parsed as a string rather than a resource,
> they can just add in the correct datatype using @datatype. In the even
> more pathological edge-case they rather have it parsed as a literal string
> rather than a xsd:string (and the fact that these are not the same in RDF
> is broken, obviously), one could add in "literal" as a datatype to handle
> that.
> 
> 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'd ditch @rel, because as put by Kavi, it has two different possible uses
> -- it's either used on a link to another page, or to convey a relationship
> to another entity on the same page.
> 
> 3) Similarly, pick either @resource or @content (or preferably, pick a
> better name like @object) and do not encourage the use of both for marking
> object. Again, the difference between @resource and @content is supposed
> to be to mark the difference between URIs and literals.

These two comments are, in fact, one. The issue is whether having a mechanism built-in RDFa whereby the system would 'recognize' whether a string is a URI and then make an internal 'switch' whether to generate a URIref in RDF terms or a literal. This was discussed at length in the working group, but it was not accepted after all. I know this is not an answer just stating facts...

One could also think (and I am just thinking out loud here!) in terms layers of RDFa, whereby a certain layer of RDFa generates only literals and no URI references. After all, your comments can be viewed as comments on RDF and not on RDFa: RDFa merely follows the distinction in RDF!


> 
> 3) Please just pick one way to do vocabularies, and so eliminate the use
> of @vocab. Vocabularies should either reference an offline vocabulary
> profile for the namespace (@profile), or specify the namespace directly
> (@prefix). @profile serves a useful purpose of allowing prefixed CURIEs to
> be used. Of course, @prefix is needed for compatibility with HTML5. I do
> not really see any reason to add @vocab. Also, as a brief warning - was
> not @profile eliminated by HTML5, and used for a bunch of other things?
> Maybe just have @vocab be used for the current use of @profile if HTML5 is
> determined to keep @profile out.
> 

@vocab is different. It sets the 'default vocabulary' and allows to use terms. Ie

<span @vocab="http://example.org#">

  <span property="me"...
</span>

would yield the property http://example.org#me

a @profile can also define terms and not only prefixes. So it serves several purposes not only to set prefixes for CURIEs


> 4) Is there really a reason to have this inline use of @prefix="ex:
> http://www.example.org"? I'd remove it. It makes misuse of URIs more
> likely, as Hixie is right on some things - people do not in general type
> URIs in correctly, usually things like a trailing # are forgotten.

I do not understand. Is your proposal that the user cannot set CURIE prefixes, only through profiles? 

> 
> 5) Also, lots of people will forget to put the URI in the
> @prefix/profile/xmlns, but they tend to get things like "ogp:title" and
> "foaf:name" right in the content. Therefore, I suggest that the current
> rudimentary state of the XHTML profile be fixed, so that the top 10 or so
> vocabularies also have their namespaces stored there, so the common use of
> "foaf:name". Rather than hide that feature (I can barely find mention of
> the default XHTML profile [3] in the doc), it should be put in an example
> early on. Just using common namespaces with a centralized directory is a
> lot more sensible for end-users than putting expecting them to remember,
> or cut-and-paste, URIs correctly.

I do not understand. Is your proposal to set up a profile registry with some of the well known prefixes included? I do not think the RDFa WG has the capacity to set up and maintain something like that. Note that the current RDFa spec allows for that, and even suggests that, but I am not sure more can be done.

Thank

Ivan

> 
> 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. Is there a way we could add something to the vocabulary
> profile that says, "for this vocabulary, create a blanknode". Otherwise,
> say to use Facebook OGP correctly, one would have to a declare a blank
> node on top of the page, i.e. about="" or typeof="". I have to agree with
> David Recordon here, asking users to do something like that is a bit
> silly. It's better to have it in the vocabulary definition. You could
> easily add:
> 
> <span property="rdfa:defaultresource">A blank node</span>
> 
> Or if you want to give that a value (unlikely, but possible)
> 
> <span property="rdfa:defaultresource"
> resource="http://www.example.com/#">The default subject of this vocabulary
> is <a href="http://www.example.com">example.com</a>.</span>
> 
> But you probably want to give it these blanknodes type:
> 
> <span property="rdfa:defaultresource" typeof="abc:review">The default
> subject of this vocabulary is a blank node of type "review".</span>
> 
> Speaking of that, we need a better description of the vocabulary profile
> parsing algorithm, it's kinda mentioned offhand the use of rdfa:uri and
> things like that, and it seems to be in this document [2]. Since it's
> important, why not just move that doc into core?
> 
> 7) And since OGP has shown that many users find it easier to cut-and-paste
> <meta> and <link> into the head rather than annotate the body, why not
> show how that can be used as the first example *before* going into the
> body?
> 
> 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.
> 
>      cheers,
>            harry
> 
> [1]http://ogp.me/
> [2]http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100326/
> [3]http://www.w3.org/1999/xhtml/vocab/
> [4]http://www.w3.org/TR/2010/WD-rdfa-core-20101026/
> 


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