RE: [ALL] RDF/A Primer Version

>Hi Ben,
>
>I think that, because no element with the id 
>attribute value "me" is actually present in the 
>document, then current specifications [3,4] do 
>not allow any conclusions about the nature of 
><#me> to be drawn from the content-type of the 
>document.
>
>As I understand it, the TAG position is that, if 
>an element with id "me" is present in the 
>document, then:
>
><#me> rdf:type ???:XMLElement.
>
>... follows (is implied? is entailed?)

I do hope they didn't actually say that, because 
therein lies the problem, seems to me.

>, because ...
>
>>From [3]: 'The semantics of a fragment 
>>identifier are defined by the set of 
>>representations that might result from a 
>>retrieval action on the primary resource.'

As I read this, it seems to say that the 
retrieval action yields a *representation* of the 
semantics of the fragID, and this representation 
defines the semantics of it, i.e. what it means. 
The most direct interpretation of what that 
means, applied to RDF, would be that the RDF you 
get from the primary resource is a representation 
which defines the semantics of the fragID; so, 
the RDF semantic theory is what should be used to 
determine the meaning of the identifiers used in 
the RDF: and that is exactly what the RDF spec 
also says.  If this is what this all means, then 
it doesn't follow at all that the fragID has to 
denote some piece of XML syntax. That would be a 
use/mention confusion, seems to me: the fragID 
*is* a piece of the XML syntax machinery, which 
is used to encode a representation: what it 
*denotes* or *means* is determined by that very 
representation. Surely that is exactly what the 
above quote says.

>
>>From [4]:
>
>   '... fragment
>    identifiers for XHTML documents designate the element with the
>    corresponding ID attribute value ...'

Again, there is an implicit pun on "designate". 
You seem to be reading this to mean "denotes" , 
but I don't think that is what the TAG group had 
in mind at all. I think they are using 
'designate' here to mean something like 
'indicate' or 'stand in for'. If they really did 
mean 'denote', then XML text would refer to 
itself, and XML would be a semantically reflexive 
language, which would be a very peculiar kind of 
thing. This doesn't seem to jibe with uses of XML 
in real life.

>(I use '???:' above because I'm not aware that 
>anyone has actually declared the class of 'XML 
>elements'.)

Indeed. It would be tricky to do.

>Then if FOAF were to declare:
>
>foaf:Person owl:disjointWith ???:XMLElement.
>
>... this can lead to (implies? entails?

Yes to both. 'Entails' is the semantic version of 'implies'.

>) an 'inconsistency' (is that the same thing as a 'contradiction'?)
>

Again, to be pedantic, "inconsistency" is a 
semantic notion while "contradiction" refers to 
the syntactic or computational signal of the 
presence of an inconsistency. But what the hell, 
as Mehitabel used to say.

>But, if I have understood correctly, Pat argues 
>[5,6] that this type of 'inconsistency', even if 
>it were to arise, would not actually cause any 
>problems, i.e. is not at all harmful in any way, 
>and is in fact very useful.

For the record, my position isn't tolerant of 
formal inconsistency, so there would indeed be 
something wrong about this situation; but I would 
locate the source of the problem as being the 
interpretation of the text you cite earlier, ie 
the claim that <#me> rdf:type ???:XMLElement.

>Please note my position given at [7]: 'I support 
>publication of this document as a Working 
>Draft'. I do not think the publication of RDF/A 
>as Working Draft should be delayed because of 
>this particular discussion thread.

I agree.

Pat


>
>Al.
>
>[3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
>[4] http://www.ietf.org/rfc/rfc3236.txt
>[5] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0152.html
>[6] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0153.html
>[7] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html
>
>>  [... much useful discussion ...]
>>
>>  Thank you all for these very useful comments. I have added warnings 
>>  in Sections 2 and 3 of the RDF/A Primer (2006-01-24) [1].
>>
>>  I would like to ask for some clarification on one issue so we can 
>>  narrow down the source of the debate. I'm particularly worried about 
>>  the implication that a URI with a # in it cannot be used to
>>  reference 
>>  a non-information-resource entity if the containing URI
>>  (without a #) 
>>  is an XHTML document.
>>
>>  Specifically, here's an alternative way to present the FOAF metadata 
>>  in RDF/A:
>>
>>  =========
>>  <html>
>>	<head><title>Ben Adida's Page</title></head>
>>	<body>
>>	<p about="#me">
>>		Welcome to my <a rel="foaf:homepage">homepage</a>.
>>		You can contact me at <span
>>  property="foaf:mbox">ben@mit.edu</span>.
>>	</p>
>>	</body>
>>  </html>
>>  =========
>>
>>  which would yield the triples:
>>
>>  <#me> foaf:homepage <>.
>>  <#me> foaf:mbox "ben@mit.edu".
>>
>>  Is this still wrong according to the TAG, because the <> URI
>>  resolves 
>>  to an XHTML document and thus <#me> cannot be a foaf:person?
>>  That is 
>>  what I understood from Alistair's early email. I want to point out 
>>  that, if that is the case, then as Mark described, that is seriously 
>>  problematic for RDF/A whose goal it is to describe the document that 
>>  is actually carrying the RDF/A itself.
>
>


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 30 January 2006 22:08:09 UTC