Re: RDF Concepts and fragids

Jonathan Rees wrote:
> On Sat, Apr 2, 2011 at 11:49 AM, Nathan <nathan@webr3.org> wrote:
>> Hmm, I read that differently, "a URI Reference in an RDF Graph", it doesn't
>> speak of URIs used outwith of RDF (as in, it doesn't try to say they are or
>> are not meaningless, just that you don't know the meaning in RDF), and when
>> one does use such URIs in RDF, surely the URI collision comes in to play,
>> such that one would write (in RDF):
>>
>>  <http://example/doc#foo> a :HTMLElement .
> 
> Right or wrong, the *ideal* is that a URI means the same thing in
> webarch as in RDF. For an RDF spec to suggest otherwise is a violation
> of webarch (as I understand it). And RDF is supposed to be the poster
> child for webarch. The RDF just puts a bit of formal dressing on top
> of what we already want to say; that dressing has to be consistent
> with preexisting meaning - it can't modify or transform or "formalize"
> it.

So which specifications give a fragment identifier preexisting meaning? 
There's HTML which is the key contender I guess, so if we look at the 
in-development specification:
[[
Fragment identifiers used with text/html resources refer to the 
indicated part of the document.
]] -> http://dev.w3.org/html5/spec/Overview.html#text-html

where "the indicated part of the document" is:
[[
For HTML documents (and HTML MIME types), the following processing model 
must be followed to determine what the indicated part of the document is.

Parse the URL, and let fragid be the <fragment> component of the URL.

If fragid is the empty string, then the indicated part of the document 
is the top of the document; stop the algorithm here.

Let decoded fragid be the result of expanding any sequences of 
percent-encoded octets in fragid that are valid UTF-8 sequences into 
Unicode characters as defined by UTF-8. If any percent-encoded octets in 
that string are not valid UTF-8 sequences, then skip this step and the 
next one.

If this step was not skipped and there is an element in the DOM that has 
an ID exactly equal to decoded fragid, then the first such element in 
tree order is the indicated part of the document; stop the algorithm here.

If there is an a element in the DOM that has a name attribute whose 
value is exactly equal to fragid (not decoded fragid), then the first 
such element in tree order is the indicated part of the document; stop 
the algorithm here.

If fragid is an ASCII case-insensitive match for the string top, then 
the indicated part of the document is the top of the document; stop the 
algorithm here.

Otherwise, there is no indicated part of the document.
]] -> 
http://dev.w3.org/html5/spec/Overview.html#the-indicated-part-of-the-document

so what would the meaning of "the top of the document" be? or "no 
indicated part of the document"? or "the first such element in tree 
order is the indicated part of the document" when there are several 
bearing the same ID, and what is the meaning of an "element" in this case:
   <div id="bar"></div>
in this case?
   <p id="foo">A sentence here</p>
in this case?
   <nav id="baz"><a href="/x">about</a></nav>
when the element was added with document.write by a script and given an 
as the page loads?

To me it doesn't even feel like HTML gives any meaning to fragment 
identifiers at all, rather that browsers simply use them to know which 
portion of a document to pull in to view. The only case I personally see 
as different, is when an /author/ explicitly gives a section of a 
document or a paragraph of text and id, to refer to that section or 
paragraph, but that really doesn't seem like they mean "the HTML 
element" at all.

Perhaps it's worth swapping out HTML from the conversation for a while 
and replacing it with something like text/plain and 
http://tools.ietf.org/html/rfc5147 ?

Best,

Nathan

> Now there are legitimate situations where there may be a divergence,
> but the starting assumption has to be what I said above. Without that
> we don't have a single global namespace, and without that we don't
> have a One Web.
> 
> Of course it's easier for the two to coincide when webarch delegates
> to RDF, as in the application/rdf+xml registration. But for RDF
> Concepts to presume to influence how FYN works for HTML files seems
> very subversive to me, and it gives completely the wrong message about
> how semantics works. We don't have RDF meaning and non-RDF meaning;
> there is just meaning, and RDF is just a tool that helps us sharpen
> what we say, like integral calculus or chemical diagrams or any other
> formal notation. It doesn't have its own kind of meaning.
> 
> (I am using "meaning" and "semantics" in the philosopher's sense, not
> in the mathematician's sense. RDF semantics is a mathematical
> semantics, so it does not (nor is it supposed to) tell us what
> something like dc:creator is supposed to mean. A particular semantics
> in the philosopher's sense would be synthesized in the usual
> compositional way via a particular satisfying interpretation. I have
> nothing against mathematical semantics but it has to be realized it's
> never the whole story, unless you're a mathematician.)
> 
> It certainly would be possible to divorce RDF meanings of URIs from
> webarch meanings - I think this is what Ian and Harry want, and I'm
> not dogmatically opposed to it. But that step ought to be done openly,
> preferably with the support of the TAG.
> 
> It might also be possible to changes webarch meanings to more closely
> match what people do and what they want, by updating 3986 and/or
> webarch.
> 
> Jonathan
> 
>

Received on Sunday, 3 April 2011 00:25:09 UTC