- From: Dan Brickley <danbri@danbri.org>
- Date: Sat, 24 Mar 2012 18:25:35 +0000
- To: Dave Reynolds <dave.e.reynolds@gmail.com>
- Cc: Jonathan A Rees <rees@mumble.net>, Jeni Tennison <jeni@jenitennison.com>, public-lod community <public-lod@w3.org>
On 24 March 2012 17:36, Dave Reynolds <dave.e.reynolds@gmail.com> wrote: >.... However, the data is not always under our complete control and > there is no universal agreement on what default fragment to use. Leaving us > either having to maintain mapping tables or try multiple probes ("when asked > for U try <U> then try <U#id> then try ..."). Not a fatal problem but > certainly an inconvenience when managing large and complex stores. Maybe we can come up with such a string? Something that isn't in current use, yet isn't too ugly? Maybe something that looks nice in UTF8 but obscure in ascii-fied form? I know well-known strings are frowned upon, but ... it's tempting. Are there values that would be legitimate as URI/IRI references, yet impossible to be HTML anchor targets? (and therefore avoid clashes?) > Problem 2: serialization > > With a convention of a single standard fragment then prefix notation in > Turtle and qname notation in RDF/XML become unusable. You would have to have > a separate prefix/namespace for each resource. In turtle you can just write > out all URIs in full, inconvenient for not fatal. In RDF/XML you can do that > for subjects/objects but not for properties (and not for classes if you want > to use abbreviated syntax). Having to declare a new prefix for every > property, and maybe every class, in a large ontology just so it can be > serialized is a non-starter. Good point. I'm mostly concerned with entity identification (people, movies etc.) rather than vocabulary, since the publishers are typically a bit less semweb-engaged. For entities, there's a bit less need to use a prefixing notation afaik. cheers, Dan
Received on Saturday, 24 March 2012 18:26:03 UTC