Re: Named graphs etc

On Mar 11, 2004, at 20:41, ext Pat Hayes wrote:

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

But they *would* obey the RDF MT rules!

Who says you can't have some *other* specialized interpretation of
an RDF graph which is consistent with a subset of the RDF MT (or
even all of it) but which is based on explicit statements using
a particular vocabulary?

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

The bootstrapping interpretation which examines a particular graph
for statements using the bootstrapping vocabulary and based on
the indicated subject of those statements and the assigned name
of the graph determines if the graph is asserted/authentic/etc.

But *not* a full RDF/OWl interpretation including reasoning
and application of closure rules, etc. etc.

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

Done.

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

Yes, but (a) when performing the bootstrapping interpretation, you
won't employ any reasoning -- taking the graph as static, and (b) if
you infer new statements then those statements are in some other
graph, so they are out of scope for the bootstrapping interpretation.

It might help to think of the bootstrapping interpretation as more
of a syntactic validation based on certain statements in the abstract
graph syntax matching certain patterns. I.e. if a graph explicitly
named :X contains a triple exactly matching

    :X trix:asserted "true"^^xsd.boolean .

then it is taken to be asserted by the graph authority/owner/publisher.

It's really a way of "faking" the XML attributes using RDF statements,
so that (a) we have a consistent mechanism regardless of serialization
and (b) we don't have to change RDF/XML to get wide deployment.

That statement itself will remain *fully* valid and true insofar as
the RDF/OWL MTs are concerned. But if the actual graph context is lost
(e.g. by a legacy, triples only store) then it simply is no longer
useful for the bootstrapping interpretation, but remains true and
(potentially, though not likely) useful to any RDF/OWL reasoners, etc.

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

Er... well, actually, alot of those parsers are not XML parsers or
built using XML parsers but are in fact, written in C/Java/Python, etc.

So it's not a matter of simply tweaking a DTD (and in fact, it's 
impossible
to write a DTD for RDF because of its bizarre [IMO] striped syntax...)

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

XML would allow you to say "just pretend this is well formed" but RDF 
parsers
are not XML parsers and thus, would be pretty anal about such "extra" 
stuff.

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

No, you misunderstand.

I mean queries which are able to make distinctions about the graph 
membership
of particular statements and the qualities of the particular graphs.

I.e., we would need a way for QLs to be able to talk about graphs and 
statements
occurring in particular graphs or kinds of graphs.

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

Right.

> but not assert.

Agreed (and never [intentionally] suggested as much).

Patrick


--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Friday, 12 March 2004 04:43:55 UTC