Graham Klyne wrote: > > > It seems to me that the requirement to find the > > > namespace-related > > > portion of a URI in isolation is not reasonable. It's also > > > not clear to me > > > what purpose it serves. > > [Brian McBride] > >SiRPAC's java API only ever passes through the full URI - it > >never passes through the URI split into the namespace part > >and the rest. If an RDF processor wishes to determine what > >schema applies, perhaps to do validation or schema directed > >editing, it needs to be able to figure out the right namespace. > [Graham Klyne] > OK, that is an answer to my second question. I do wonder if it's a real > requirement. > > It seems reasonable to me that an application doing schema directed > processing might have some kind of a priori knowledge of the schemas being > used (by embedded labels, implied by the application, or other means), from > which the URIs defined by each such schema can be deduced. I agree with Graham. Furthermore, why should the following be so strongly related - a Class or Property URI (that is, its *name*) - the URI of the schema defining/describing that Class or Property As practical as it is (to give a clue to the parser about who describing what), this should not be a fundamental requirement, or then RDF uses *locators* instead of *identifiers*, and that's a shame because URLs are less general than URIs. > (There's still a potential messy problem of two schemas that define the > same URI.) this anyway, would be a very *bad* design for a schema ! A schema writer should only use URIs "belonging" to him (i.e. over which he has control). [Brian McBride] > >So either the java api needs to change or there needs to be > >a way to figure out the namespace. I guess I'm uncomfortable > >with Dan's suggestion of the parser adding statements to the > >model - not its job to modify the model it is given really. that's what magic with meta-data: What if I say that the parser does not *modify* the model, but it annotates it... Pierre-AntoineReceived on Tuesday, 1 August 2000 02:46:16 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:43 GMT