On 29 Jan 2008, at 14:42, Ian Horrocks wrote: > On 29 Jan 2008, at 14:28, Bijan Parsia wrote: > >> >> On 29 Jan 2008, at 14:12, Ivan Herman wrote: >> >>> Well... You might think that the issue is only for complicated >>> URIs like http://a.b.c/?qqq&www (which may indeed be a >>> pathological case for a property name) but it is not. We (ie, >>> W3C) had long discussions in the past few months with IPTC[1] >>> who, for historical reasons, have a bunch of URI-s of the form >>> http://a.b.c/123 (ie, with numerals at the end of the URI >>> string), but they would like to use RDF & co for, eg, their >>> definition of NewsML[2]. Ie, they may have very good reasons to >>> use property names of this form in an ontology. >>> >>> Ie: I would be cautious in introducing such restriction... >> >> I concur, > > Still seems bizarre to me that our syntax spec doesn't specify > names in a way that ensures that they can be written down using the > standard concrete syntax -- or, looked at the other way round, that > the standard concrete syntax doesn't allow us to write down all > legal names. But what do I know. I discussed this with the chair of RDF Core after their second last call intending to make a LC comment on it, but it seemed that the obvious fix wouldn't happen so I dropped it. Yep, it's a weird thing. [snip] >> (And, as I've said long ago, I wouldn't mind tightening some of >> the serialization requirements in the RDF/XML (i.e., order of >> axioms, etc.) In fact, I think that's highly desirable.) > > Doe this impact on round tripping? I don't *think* so as long as the prettyprinting step doesn't change any constructors...which it shouldn't. (I.e., roundtripping is Functional syntax to graph; pretty printing is function syntax *or* graph to a specific linear form.) So I think round tripping (RT) is a component of "nice serialization" (NS), so the dependancy runs from RT to NS. Even without RT, some specced NS would be a good idea. Cheers, Bijan.Received on Tuesday, 29 January 2008 14:52:03 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 January 2008 14:52:10 GMT