Re: Fragment Identifiers and Agent Perspectives

On 10/10/2011 09:22 PM, "Martin J. Dürst" wrote:
>> Part of the reason that we're going to this trouble is to finally
>> establish what a fragment identifier means when used in a document.
>> Jonathan stated that the TAG may update RFC 3986 to clarify what a
>> fragment identifier means - that's a good idea.
>
> The TAG cannot update RFC 3986. The IETF can update it. Of course,
> members of the TAG can help with that update. But given it's an Internet
> Standard, and given the update seems to be just about a few words, and
> given the goal is that even "pedants should be able to follow their
> nose", I'd expect quite a bit of resistance (if only passive, but that
> might be enough).

I tend to agree that this discussion can be pedantic.

However, I also find myself having to explain this to Web developers 
often and when they ask me which spec states what a fragment identifier 
means on the semantic web and what a fragment identifier means on the 
document-based Web, I don't have a good place to point them for the 
semantic web case. I've pointed people to RFC 3986 before, but it 
clearly doesn't talk about how to use fragment identifiers on the 
semantic web.

The existence of the semantic web case makes them then question whether 
the fragment identifier section in RFC 3986 is up to date at all. I 
typically shrug and tell them that I don't know if RFC 3986 really ever 
considered the semantic web at all since it doesn't really elaborate on 
how fragment identifiers can be used to refer to sections of a document, 
application state or semantic concepts.

So, while the discussion can be pedantic - I'm having a very hard time 
pointing people that are just learning about this stuff to a normative 
specification that talks about fragment identifiers and semantic web / 
Linked Data concepts with any authority.

>> You're also going to
>> have to make sure that all specs utilizing RDFa update the Media Type
>> registrations to achieve the spec-to-spec jumping that is required to
>> understand how a fragment identifier is interpreted.
>
> Is it necessary to update the registration? Isn't it enough if it's in
> the relevant spec?

The TAG has made it seem to me as if this is not enough. I can see their 
point and I don't see much harm in making the linkages between Media 
Type and their corresponding specification more clear.

> In the limit, if I have a registration for an XML-based media type, and
> that registration points to a spec, and that spec says that it's okay to
> have foreign elements/attributes (and says or implies that the semantics
> of these elements/attributes apply), and these foreign
> elements/attributes have a spec that's easy to find (e.g. via a
> namespace page) and that spec says how to treat some of the fragment
> identifiers, and isn't in conflict with the main spec, then the chain of
> reference should work, shouldn't, even for pedants?

It works for some, doesn't for others. I think that's why we're 
discussing this. It wouldn't take much effort to do something that 
worked for everybody and provide documentation that waved its hands a 
bit less.

>> What a fragment identifier means is dependent on the Agent's
>> Perspective. The Agent could be a User Agent, or it could be Semantic
>> Agent. How the fragment identifier is interpreted is based entirely on
>> who is asking the question.
>
> As Noah has said, that seems a to be a bad idea, because any kind of
> agent could do anything.

... but this is already happening on the Web, isn't it? That's kind of 
the point of what Roy was saying, right - anybody can do anything?

>> http://example.com/foo#bar
>>
>> A User Agent processing an HTML5 document would be looking for id="bar".
>>
>> A Semantic Agent processing an HTML5+RDFa document would be looking for
>> the concept described using about="#bar".
>
> This is true to the extent that agents (I don't like this word
> capitalized, sorry) may be only interested in a subset of fragment
> identifiers, or may only be able to handle a subset of fragment
> identifiers. But the question of what each piece of software can deal
> with should be separate from the question of what the fragment
> identifier 'means'.

I thought what a piece of software can do with a fragment identifier was 
clear. I thought the bit that wasn't clear is what the fragment 
identifier 'means'? What am I missing?

>> There are times where someone could do the following:
>>
>> <div id="bar" about="#bar">...</div>
>
> If you subscribe to the theory that these identify two different things,
> then RFC 3986 clearly says this is a bad idea.

I agree, my example was misleading and detracted from my point, which is...

> I don't think there's much more we can say.

Well, technically, they do identify two different things - one 
identifies a document fragment, the other identifies a semantic concept. 
You can wave your hands a bit and say they're "well, they're effectively 
talking about the same thing". We do this hand waving quite a bit in Web 
Vocabulary documents, for example:

http://payswarm.com/vocabs/security#publicKey

#publicKey identifies a document fragment that contains human-readable 
text that explains the public key vocabulary term. If one were to 
extract RDF from the document (via RDFa), they would also be able to 
access the machine-readable data associated with the vocabulary term.

I agree that it would be bad to have the #publicKey document fragment 
talk about public keys and #publicKey semantic concept talk about 
private keys. However, I don't agree with this statement - "I don't 
think there's much more we can say".

> One of the very basic ideas of URIs/IRIs is that there's a single space
> so that overlapping usages are possible when they make sense (even if
> they don't always do). I think that also applies to fragment
> identifiers. It's easily possible to have some static fragment
> identifiers for the case that JavaScript isn't active, but use
> JavaScript if it's active.

I agree.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Standardizing Payment Links - Why Online Tipping has Failed
http://manu.sporny.org/2011/payment-links/

Received on Tuesday, 11 October 2011 03:21:38 UTC