Re: Named graphs etc

>On Mar 10, 2004, at 19:08, ext Pat Hayes wrote:
>
>>>Would constraining the interpretation of a given class of properties to
>>>the graphs containing the statements in which they occur be overloading
>>>RDF/OWL?
>>
>>Yes, I think so. It would require the entire MT to be rewritten, to 
>>do it rigorously. It basically introduces indexicals into the 
>>language.
>
>Wouldn't the distinct bootstrapping interpretation phase provide
>a reasonable detour around overloading the RDF MT?

Well, maybe, though I guess I don't follow how in detail. But then we 
shouldn't represent the required info in the RDF.  RDF triples are 
required to obey the RDF MT rules.

>I.e., it's
>a specialized interpretation done by agents savvy about the
>bootstrapping machinery for testing assertion and authentication,
>such that, for other agents, the statements are innocuous (though
>also useless) without that specialized "pre-interpretation" of
>the graph.
>
>???

I agree, "???" I don't know what you mean by pre-interpretation.

>
>Please forget about the "thisGraph" trick. Presume that all
>graphs have distinct identity and all bootstrapping qualification
>statements must refer to each particular graph distinctly.

Ok, will do. Ignore gripe in previous message about this.

>
>>And it has all kinds of odd operational consequences for inference 
>>engines; for example, in OWL, how would you know whether or not two 
>>graphs references were referring to the same graph?
>
>Because the two graph references would refer to different graphs,
>since those graphs would be denoted either by distinct URIs or
>by distinct bnodes.

No, that won't work. In OWL you can infer that

ex:thisURi owl:sameAs ex:thatURI .

and the grounds for this conclusion can be arbitrarily indirect, eg 
might commonly involve reasoning about class cardinalities.

>>>Or would this rather be more of an application layer above,
>>>but not directly impacting RDF/OWL?
>>>
>>>>... what is more minimal than a single XML tag?
>>>
>>>It depends. For TriX, that is easy. And in fact, TriX *already* provides
>>>that attribute, and has since the first published version.
>>>
>>>But for RDF/XML, you aren't honestly proposing a change already?! ;-)
>>
>>Maybe Im not familiar enough with XML, but would adding a property 
>>to an element amount to a substantial change to RDF/XML?
>>Seems kind of piffling to me. I assumed one could always add 
>>properties without breaking anything.
>
>Ask Dave...  ;-)
>
>Technically, it's a trivial addition. In practice, though, it 
>requires *every* RDF parser
>to be updated. And since the new specs just required all the parsers 
>to be revamped,
>retested, etc. I don't think the parser folks would be very keen 
>about *any* changes
>so soon after the new specs.

I'm tempted to say, f*** the parser folks. I mean, its not like we 
are asking them to rewrite C code or something. They are dealing with 
XML, for God's sake, and the touted advantage of XML is that it makes 
parser tweaking trivially easy. What is this, one line in a DTD? The 
kind of change that a ten-year-old could make without screwing it up?

In any case, isn't there any way to tell an XML engine that its OK to 
have some extra structure in the XML? Or is XML even more badly 
designed than it seems to be? On reflection, don't answer that last 
question.

>>>Also, a single XML attribute is easy for one serialization, but what about
>>>all the other forms of expression? N3, Turtle, TriX, Squish, 
>>>TriQL, RDFQL, RDFQ,
>>>RDQL, etc. etc.
>>
>>Well, good point, although the QLs are kind of irrelevant since one 
>>wouldnt expect to be asserting a query.
>
>Actually, one *would*.

No, really, one would not. If anyone thinks they are ASSERTING a 
query then they need to get their knickers untwisted.

>
>If a graph makes it past the bootstrapping tests, and one has a KB and
>QL that preserves graph membership (either by architecture or by
>distributed queries over sets of graphs) then one would *need* to
>hook into those bootstrapping statements to build the higher layers
>of trust.

Hook into, sure, but not assert.

Pat



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

Received on Thursday, 11 March 2004 13:41:41 UTC