Re: Small @profile question

Ivan Herman wrote:
>>>> Regardless, I trust that the Working Group has weighed up all of the pros and cons, thus making the inclusion of @profiles in RDFa an informed decision made with wide open eyes. As mentioned in my original mail, this was more for my own peace of mind ensuring that the raised points had been fully considered / are not new :)
>>> Yes, I think we all know that this is the only major change in RDFa1.0 vs. RDFa1.1, all other changes are more cosmetic in nature. And we did have a lot of discussions. But some feedbacks we got from potential RDFa consumers like Facebook seem to indicate that may become a very useful feature nevertheless. I personally also expect that most of the RDFa processors will have some sort of a caching mechanism for the well known profiles, ie, processing the RDFa files will be less dependent on the possible network problems...
>> Sorry Ivan, I really didn't mean to come across as condescending or to cause any offence, was more trying to acknowledge that I think you've all done great work, and even though I'm asking questions, I do trust the decisions you've all made :)
> 
> Nathan, there is absolutely no reason to apologize and I did not take your questions as condescending _at all_! You are absolutely right is asking these questions which do show the potential dangers in using profiles. What we, as a community, have to decide is whether the advantages of using profiles outweight the potential problems or not, and that should decide whether the feature should remain in the final RDFa spec or not. So your questions are valuable for that discussion...

Cool, and thanks for your replies, they've really helped me nail my 
concerns :) I think getting to the crux of it,

When parsing an RDFa Document, if a CURIE is unresolvable then
  (1) discard the would-be triple
  (2) emit a Warning and (1)
  (3) emit an Error and (1)

I guess if I was building a parser within a generic scraper then I'd 
instinctively go with (1), if I was building a parser in a library or a 
user agent implementation then I'd go with (2), and if I was building an 
RDFa validator (which checked the would-be RDF Graph) then I'd go with (3).

As yet I'm personally undecided as to whether the benefits outweigh the 
potential problems, and have yet to fully consider Marks recent 
clarification on his profile related objection. At the same time though 
I'm very aware that it's late in the day, that I'm not bringing a better 
proposal to the table which addresses these potential problems and the 
ones @profile hopes to solve, thus unsure if I'm actually doing any good!

I can say though, that given the current status where @profile is in 
RDFa Core 1.1, then I'd be keen to see:
  - a note to implementers that stipulates a warning should be emitted 
if a profile cannot be retrieved or a curie cannot be resolved
  - an !Important note to authors that makes them aware that if a 
profile cannot be retrieved then triples which rely on said profile will 
not be included in the graph produced by parsing the document.
And I'd hope some first-choice RDFa validator (probably on w3c) was 
implemented such that an error was produced if a curie cannot be 
resolved in an RDFa document.

Best,

Nathan

Received on Friday, 10 September 2010 10:18:42 UTC