- From: Nathan <nathan@webr3.org>
- Date: Mon, 01 Nov 2010 15:04:54 +0000
- To: Toby Inkster <tai@g5n.co.uk>
- CC: public-rdfa-wg@w3.org, Manu Sporny <msporny@digitalbazaar.com>
Toby Inkster wrote: > On Mon, 01 Nov 2010 11:17:04 +0000 > Nathan <nathan@webr3.org> wrote: > >> and if we add in a simple rule saying that strings which aren't >> curies map to PlainLiterals then we can also enable: >> >> context.createTriple(":me", "foaf:name", "nathan" ); > > I assume by CURIEs in the above, you mean CURIEs-or-URIs, so full URIs > would be OK. I don't think that's a good idea though. It could result > in surprising consequences. > > Consider the following (and let's forget daylight savings yesterday): > > context.createTriple(":me", "vcard:tz", "UTC+01:00"); > > You may surprised to find that <UTC+01:00> is a syntactically valid > URI. It has a scheme of "UTC+01" (which is unregistered, but we > shouldn't require implementations to track which URI schemes are > registered) and a scheme-specific part of "00". Indeed, things have the potential to go a bit pear shaped when you get to the object position with the full scope of all types of RDFNode and limited ways to distinguish between them. The example above can be simplified down to any uri like "http://example.org" is that to be an IRI or a PlainLiteral? Since this issue would only be found in one place, and since the benefits of adding this functionality could make a huge difference to the API, then perhaps it's worth addressing with rules for the common case, limiting to curie or absolute uri and introducing "<>" wrappers for safe or relative IRIs. Or we could say all strings in the object position translate to PlainLiterals, or many other approaches. I guess question one is, is it worth giving it a go? > APIs should try to avoid surprises. I couldn't agree more with that statement, to remove unexpected functionality is a primary goal. as an aside: imagine how much easier things would be if languages such as ecmascript provided first level support for URI or IRI! Best, Nathan
Received on Monday, 1 November 2010 15:05:43 UTC