- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 26 Sep 2011 12:34:25 -0500
- To: RDF Working Group WG <public-rdf-wg@w3.org>
Perhaps the best way to resolve this interminable debate would be to start from the other end. Rather than implementors pointing out the horribleness of various proposals, could we have a list of what implementors would consider to be the least objectionable behavior? I myself have no idea why "xxx@lll" is so very much worse than "xxx" paired with the datatype langbase:tag, but I am quite willing to be told that there is a consensus among implementors that this is so (or whatever in fact is the consensus) and then I am sure I can design an RDF modification which will realize that desired behavior and have a reasonably coherent semantics. I would however observe that as tagged literals are exceptional, and as we are proposing to make some kind of change to the existing spec, that *some* amount of change to existing code might have to be contemplated. If no changes are allowed at all to any existing deployed code, the WG should just pack up now, define RDF2 to be the same as RDF1 and declare its business done. We all have other things to do, I am sure. Pat On Sep 26, 2011, at 4:51 AM, Jan Wielemaker wrote: > On 09/26/2011 11:28 AM, Richard Cyganiak wrote: >> You understate the issues. >> >> Every existing application that uses the Literal.getLexicalForm() call of some API to get at the xxx part of xxx@lll would have to be changed, because the lexical form of xxx@lll is now xxx@lll. >> >> That's a complete non-starter. > > I fully agree. Also note that APIs for (notably in-core) RDF stores can > now typically work on a single shared representation of the literal. If > we add a tag to the literal many of the operations will have to create a > copy without the tag. I'm not saying this cannot be solved, but I fear > it will be natural nor pretty, especially for existing stores that did > not anticipate this in their design phase. > > I must admit that I'm only following this from the sideline. As an > implementor I'm starting to get worried about some wild ideas though. > The solution I still like best is that foo@tag is the same as > "foo"^^langbase:tag, where langbase is some to be decided prefix for > language identifiers. Any implementation should be fairly comfortable > with that (typically it will just simplify things). > > I understand things get complicated if we want to attach semantics to > the these datatypes, so I'd propose not to do that. Most likely others > will make an attempt. > > Regards --- Jan > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Monday, 26 September 2011 17:34:54 UTC