- From: Holger Knublauch <holger@knublauch.com>
- Date: Sat, 2 Feb 2013 06:59:02 +1000
- To: Semantic Web community <semantic-web@w3.org>
On Feb 2, 2013, at 1:27 AM, David Booth wrote: > If prefixes are never re-defined then the SPIN engine only needs to know > the set of prefix definitions, so if the parser can supply them after > parsing, then that would work fine. But Turtle allows prefixes to be > re-defined: > http://www.w3.org/TR/turtle/#prefixed-name > so that means that the same prefix could be bound to different URIs at > different points, in which case the parser would have to know about SPIN > in order to properly expand the prefix in """... ex:grandParent ...""". > > This may be an edge case, depending on one's usage style. Personally, I > would not advocate redefining prefixes, but I seem to remember that > there was a good reason for permitting redefinition, though perhaps in > hindsight it was a mistake. Fortunately, an ambiguous definition would > be easy to detect, so I think it is a minor issue. Ok, this is indeed only a theoretical corner case. The only way of having a file that redefines a prefix appears to be by manually editing the Turtle with a text editor. Jena for example would not even remember this information and thus always prints the prefix declarations to the beginning of the file. So given that we are in hand-editing mode, then the editor can also easily see the consequences and can change or move the embedded SPARQL queries. Overall, allowing prefixes to be used is a fragile aspect of the simplified syntax, but this is a consequence of trying to have a simple, user-friendly solution. For a clean solution, we already had the SPIN RDF syntax. >> >> Yes, storing prefixes as triples may be a useful extension to RDF >> anyway, independent of SPIN. > > Yes, I think it would be good to standardize that. Parsers often keep > track of the namespace prefixes, along with some other metadata such as > filename or URI of the RDF source. It would be nice to have a standard > way to access such information from within RDF or SPARQL. I guess the current design is another legacy of having started with RDF/XML as the default serialization - too much proximity to XML in the early days of RDF. Holger
Received on Friday, 1 February 2013 20:59:41 UTC