Re: Ongoing objection to RDFa Profiles format (as XHTML+RDFa)

Ivan Herman wrote:
> Nathan,
> 
> Let us try to keep focussed:-) I have a lot of sympathy on what you write about RDFS3.0 (whatever the name is) but we should not solve that issue in this working group.
> 
> There are two different issues that we are discussing
> 
> #1: whether we have profiles in the first place
> #2: if the answer to #1 is 'True', what is the format of that file (at present, it is RDF, others would prefer to use another format)
> 
> This thread is, essentially, on #2, whereas your arguments are on #1 (well, against #1).
> 
> So I will comment on #1 a bit, but keep in mind that this is not the issue this thread is discussing, so we may have to take it 'elsewhere', so to say.
> 
> - I _do_ see the dangers you are referring to. But I expect, in practice, much less problems with those than they way you describe. Indeed, I do not expect a proliferation of profiles all over the place; I would rather expect a small number of profiles published by organizations like google, Creative Commons, Facebook, the New York Times, etc. These profiles will not really change frequently. I would also expect implementations to have some sort of a caching mechanism at least for the best known profiles, so that the profile URI would be used as an identification for those well known profiles (I know my implementation has that; a complete implementation would probably need an extra crontab job to refresh those profiles once a day, but that is easy to set up).
> 
> No, these are not full solution and there are many corner cases where it can go wrong. I know that. But all this is not really different from, say, the way GRDDL is defined or, to take a somewhat more remote analogy, the way xml schemas or dtd-s are used in practice.
> 
> - There is one aspect of profiles that you seem to miss. Profiles can be used for prefix mapping but also for term mapping. Although I can see how the prefix mapping could be handled by some sort of an OWL based reasoning (though I do not see that happening soon), term mapping is a different issue. And, in many ways, the real value of profiles is the term mapping. It is the fact that lambda HTML authors can simply write
> 
> <div profile="google-profile-uri">
>     <span property="googleterm1" content="blabla"/>
>     <span property="googleterm2" content="yepyepyep"/>
> </div>
> 
> and still generate proper RDF. If you look at the long (sorry, looooooong) discussion on the HTML5 group, for example, on the usage or not of namespaces or anything that is remotely looking like those, if you look at the argumentations around microdata vs. RDFa, in many cases that is where it boils down to. To make it a little bit more extreme: if RDFa cannot provide some solution for these term mappings, then it will be used only for complex cases where the microdata model breaks down (essentially, when using lots of different and sometimes esoteric vocabularies). By providing term mappings, RDFa can be used for simple cases, too.
> 
> That is why my feeling is (and, I believe, the feeling of the working group) that the very real downsides that you describe in your mail are acceptable dangers in view of the overall gains...

Hi Ivan, Mark,

I may be forced to agree with you, as the open issues around HTML and 
general web arch run deep (sorry, deeeeeeep! :-)) and need to be 
considered, one huge one is the issue of distributed extensibility [1] 
where there is currently a poll going on [2] in which there are two 
proposals, the first of which (an svg like approach [3]) has been 
recommended by the TAG [4], whilst it looks like the bulk of the HTML WG 
is going with the zero-edit proposal [5] which heavily relies on RDFa 
(or microformats) to resolve most of the use-cases being considered.

Thus, considering what you say re the extreme case, together with this 
and 'ISSUE-120 Use of prefixes is too complicated for a Web technology' 
then I'd have to agree that these are acceptable dangers in view of the 
overall gains (primary overall gain being people actually using and 
supporting RDFa!).

I also have to agree that the solution I proposed is not for this WG and 
will need to be handled at a sem-web+linked-data community level, 
perhaps as part of a Reasoning and Inference WG and some concerted 
effort to raise awareness.

Back on topic, with regards the format of RDFa profiles being RDFa, 
whilst Marks concerns are also valid, and in some ways touch on the 
aforementioned distributed extensibility issue, and even though I agree 
with them from a architectural standpoint - I feel that all things 
considered, having a dependency on RDFa Profiles (and thus RDF(a)) 
introduced lots of places is actually beneficial to the goals of this 
working group and helps us get to where we want to end up.

It's a strange thing to go against your better judgement on things like 
this, and that of your peers, and the TAG - this WG stuff is tougher 
than I thought - but then perhaps if I view this us getting us 75% of 
the way there in web-scale terms, even if not "The Right Way", then 
maybe we can clean up and get the remaining 25% of the way when the time 
is right and the stage is set.

So, all things considered then I agree and have to +1 RDFa Profiles, 
marked up in RDFa - unless of course there's a huge and sudden swing in 
the general direction of the html and linked data spaces (most of the 
web!) in the next month - how likely?

Best,

Nathan

[1] http://www.w3.org/html/wg/tracker/issues/41
[2] http://www.w3.org/2002/09/wbs/40318/issue-41-objection-poll/results
[3] http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg
[4] http://lists.w3.org/Archives/Public/www-tag/2010Oct/0034.html
[5] http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-41

Received on Friday, 8 October 2010 10:09:20 UTC