- 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