Re: Named graphs etc

On Mar 12, 2004, at 14:11, ext Chris Bizer wrote:

>
> Hi,
>
> another question, that I think would be interesting to discuss. We 
> always
> speak about agents referring to graphs.
>
> What about agents referring to parts of graphs e.g. statements?
>
> I have discussed this with Jeremy before and we didn't get to a clear
> solution. Take for example agent A asserting G1 and publishing it in
> Doc1.trix
>
> G1 (ex:water ex:is ex:blue.
>         ex:sky ex:is ex:blue.
>         G1 trix:assertedBy ex:AgentA)
>
> Now agent B wants to assert, that "Sky is blue" is false. And/or he 
> also
> wants to assert that he doesn't believe the assertion of agent A that 
> that
> the "Sky is blue" without questioning that agent A asserted G1.
>
> I see different approches on different levels for this.
>
> 1. Agent B could assert
>
> G2 (ex:sky ex:is ex:blue)
> G3 (G2 ex:truthValue ex:false.
>        G3 trix:assertedBy ex:AgentB)
>
> Meaning he would repeat the part of G1 he wants to talk about and make
> assertions about the repeated part. With this solution it is not 
> possible to
> figure out that B was speaking about a assertion of agent A and not a
> assertion of agent C. Is this a problem?

I'm not sure I can see the need to make explicit that agent B
disagreed with agent A. That will be clear from the contradiction
that will arise if you merge the two graphs.

I view graph qualification as simply a form of power-operation
over the statements in that graph. Thus, I presume an implicit
rule such as

IF
    :X ( ?s ?p ?o )
AND
    :X trix:assertedBy ex:Bob .
THEN
    :s a rdf:Statement ;
    :s rdf:subject ?s ;
    :s rdf:predicate ?p ;
    :s rdf:object ?o ;
    :s trix:assertedBy ex:Bob .

(in which case, we'd need to broaden the rdfs:domain of
trix:assertedBy to include statements, of course...)

Similar inferences could be made in terms of authority, scope,
relevance, etc.

>
>  I also took a look at the TAG Web Architecture Draft. In section 4.4. 
> they
> recommend: Language designers SHOULD provide mechanisms for identifying
> links to other resources and to portions of representation data (via
> fragment identifiers). So let's try fragment identifiers :-)

Grrrrr....  Do *not* make me come over there!   ;-)


> 2. Agent B could assert:
>
> G4 (G1#ex:sky/ex:is/ex:blue ex:truthValue ex:false.
>        G4 trix:assertedBy ex:AgentB)
>
> The s p o parts of the fragment identifier include other fragment
> identifiers, they would have to be escaped somehow to prevent 
> fragments of
> fragments and to allow parsing.
>
> In this solution I think agent B refers directly to the graph G1 which 
> has
> been asserted by A, thus we have a direct link between A and B and 
> know B is
> not talking about assertions of C. Do you agree? What do you think 
> about the
> fragment identifier approach?

I don't think it's necessary to specify where a particular statement
occurred or who asserted it in order to disagree with it. Just
assert the opposite and eventually, the rest will fall out from
the contradiction (presuming one has kept track of who said what and
where...)

So no fragment identifiers are needed (thankfully).

>
> 3. Another possibility are fragment identifiers on serialized document
> level, something like
>

> G4 (doc1.trix#someXPathExpression ex:truthValue ex:false.
>        G4 trix:assertedBy ex:AgentB)
>
> I think XPath doesn't work, because of the TAG finding on the relation
> between URI, resource and representation and our definition that a 
> graph
> name refers to a equivalence class of graphs. Did I get this right?

Seems so. XPath is concerned with particular serializations, not with
graphs, so if mulitple serializations all equate to the same graph, then
stuff gets pretty messy pretty fast if you try to equate all variations.

Even TriX doesn't help there, despite being far more normalized than
RDF/XML, because there is no fixed ordering of triples.

Patrick


>
> Chris
>
>
>

--

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

Received on Friday, 12 March 2004 08:45:28 UTC