Re: Change Proposal for HttpRange-14

On Sat, Mar 24, 2012 at 7:25 PM, Dan Brickley <danbri@danbri.org> wrote:
> 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?)

One that is both a valid URI/IRI reference [1] and cannot be an HTML
anchor [2] is the *empty* fragment identifier.

Granted, it is in current use and has a debatable appeal. For better
or worse it's used by a certain number of vocabularies/ontologies, for
instance RDF Schema. It's also used by OGP (see the Turtle returned by
a "curl -Haccept:text/turtle http://graph.facebook.com/<your-id>").
Even so, in the generic case I think find it more palatable to append
just "#" as a means of minting a "NIR" IRI from a canonical record
IRI, than to attach some redundant word like "#thing" or "#it", or an
oddity like "#_".


>> 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.

I agree.

Best regards,
Niklas

[1]: http://tools.ietf.org/html/rfc3986#section-3.5
[2]: http://www.w3.org/TR/html5/elements.html#the-id-attribute


> cheers,
>
> Dan
>

Received on Saturday, 24 March 2012 23:10:30 UTC