Re: status of non-prefixed values in @rel

Hi Shane/Ben,

Let's not get too melodramatic, talking about deal-breakers, 'evil'
unwanted triples (that's nothing to do with this debate!) and such
like. We know we all want @rel="next" to work, and no-one has ever
said they want otherwise.

But we put the issue onto the back-burner before because we couldn't
find a solution that was acceptable to everyone, and it was taking up
time. I think everyone generally agreed with the 'preprocessor'
approach, but since no-one ever wrote that up in any meaningful way,
it meant that it was pretty academic.

So at this late stage a proposal needs to be more than just a general
declaration of what we would like to achieve -- it needs to be some
actual text for the specification, and an indication of where in the
spec that text would go. When we have that we can discuss the
proposal, and vote on it, and then we'll all be happy bunnies.

I've never said that this issue is not solvable; the problem is rather
that there are lots of ways that the functionality could be achieved,
but when you actually get to the point of putting one or other
proposal into the spec in black and white, most of the solutions we've
had so far have had one problem or another.

Regards,

Mark

On 16/01/2008, Shane McCarron <shane@aptest.com> wrote:
>
> FWIW, this is a deal breaker for me as well.  The only use case I have
> for this stuff at all is rel="next" and rel="license".  You can talk all
> you want about unwanted triples being generated and how evil that might
> be, but I *WANT* these triples from my existing documents.  And I do not
> want to have to go back through everything I have ever done and change
> it just to get them.  If that's what we are building here, we have failed.
>
> I don't think it is at all necessary to generalize this with regard to
> CURIEs.  This has nothing to do with CURIEs.  I appreciate that there is
> a sort of issue with generalized processing of CURIEs if your
> implementation wanted to process CURIEs in an early phase of parsing,
> but thats just an implementation detail.  The implementation needs to
> ignore non-prefixed rel and rev values except for those from our list -
> those it needs to pretend have out prefix.
>
> This is really important to the XHTML community.  rel=":next" is not
> acceptable to me, and I cannot imagine it would be to the rest of the
> troops or to the great unwashed out there.  I am pretty sure that Steven
> agrees with me on this - Steven?
>
> Ben Adida wrote:
> > Manu Sporny wrote:
> >
> >> Not having rel="next" generate a triple in the default graph isn't a
> >> deal-breaker as far as I see it, especially since we leave it up to the
> >> parsers to generate those triples in other graphs, if necessary.
> >>
> >
> > The more I think about it, the more I realize that it *is* a
> > deal-breaker for Creative Commons. After all, it's one of the driving
> > use cases! Creative Commons is adopting RDFa because "license" was added
> > as a reserved word more than 2 years ago, and it was understood for
> > *years* that rel=RESERVED_WORD would yield a triple.
> >
> > I do have to apologize for somehow thinking this wouldn't be an issue
> > last month. I was very very wrong.
> >
> > Saying that "parsers may wish to generate a triple if they want" doesn't
> > solve the problem at all: when we tell publishers what RDFa to write, we
> > need to ensure that *all* compliant parsers will find the triple.
> >
> > -Ben
> >
> >
>
> --
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
>
>
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Wednesday, 16 January 2008 08:06:57 UTC