More on contexts, and 'about=' <URI-reference>

At 08:29 AM 6/23/00 +0200, Pierre-Antoine CHAMPIN wrote:
>Graham Klyne wrote:
> >
> > Folks,
> >
> > I've just noticed that the RDF M&S document section 2.2.1, production [4],
> > allows an RDF statement to have a URI-reference in an 'about=' clause.  The
> > text three paragraphs below talks about a 'subcomponent' of a resource in
> > relation to fragment identifiers in 'about='.
> >
> > I believe this could be in conflict with the formal model, which states
> > that the subject of an RDF statement is a _resource_.
> >
> >  From RFC 2396:
> >
> >           The resource is the conceptual mapping to an entity or set of
> >           entities,
> >
> > a fragment identifier has meaning only in conjunction with some specific
> > _entity_ associated with a resource (a MIME type is needed for it to be
> > interpreted).  I'm not sure what a 'subcomponent' of a resource can be
> > taken to mean.
>
>as I understand it,
>this is based on the assumption that most URIs refer to a unique entity,
>so the resource and the entity can be considered equivalent.
>I guess most will agree that this assumption is too strong.

As I understand URIs and resources and entities, that assumption is too 
strong.  Especially given that RDF is supposed to be capable of describing 
any web resource.

>Anyway, people are much more interested in entities
>than in "resources" according to the definition above.
>What I want to make clear is that, even without using fragment identifiers,
>RDF description often refer to *one* of the entities mapped by the resource,
>rather than the mapping itself.

Hmmm... the RDF M&S document, section 5, is quite clear that RDF subjects 
are called "resources".  It also states that these resources are identified 
by URIs, so I think it is reasonable to assume that RDF resources are meant 
to be the same set as web resources.

>Which brings us back to an idea you raised, Graham :
>storing with each triple the context it was stated in.
>To take back Dan Brickley's example, with the W3C logo :
>
>  I use the syntax (Subject,Predicate,Object,Context) :
>
>  (http://w3.org/logo , s1:imageType , s1:GIF , http://here.com/foo.rdf)
>  (http://w3.org/logo , s1:imageType , s1:PNG , http;//there.fr/bar.rdf)
>
>without contexts, those two statements would be contradictory,
>though they are both right, in a sense.
>
>with context, they is no more contradiction;
>we can just infer that the two contexts do not share a common view of the 
>logo,
>and that it won't be safe to mix statement from both of them.

I appreciate your raising the issue of contexts again, and I'll come back 
to that.  But I am not sure that contexts are the right way to distinguish 
between the various entities that may be associated with a resource.

I cite TimBLs paper on "interpretation properties", 
<http://www.w3.org/DesignIssues/InterpretationProperties>, in which he 
argues that the appropriate way to model the language of a value is as a 
relationship between them, i.e. a property.  E.g.

   [Some-resource] --Name--> [Name-resource] --lang:en--> 'Peter'
                             [             ] --lang:fr--> 'Pierre'

etc.

My interpretation of this is that when one employs content negotiation (in 
a broad sense of this term) to select differing representations of a 
resource --different entities-- then the metadata that is used to identify 
the desired entity should be treated as an interpretation property.  It's 
not the only possible approach, and I concede that contexts _could_ work 
for this purpose, but it seems more helpful to use an already-documented 
approach where it can serve.  In this case, the relationship between 
interpretation properties and content negotiation seems to neatly bridge 
the correspondence between URI, resources and entities.

>NOTE1 :
>the 4-uple model (subject, predicate, object, context) could be built 
>*above* RDF,
>by means of reification.

This is a useful validation of some thoughts I have been brewing.  You may 
recall that I had been looking for a way to model contexts in RDF without 
incurring the overhead of full reification.  What you describe above, and 
my own thoughts are that this can be done not by trying to change the 
abstract model in any way, but by never actually instantiating the abstract 
model directly (previously, I had thought of all implementations as direct 
instantiations of the model).

The key for me was the comment someone made that it is possible to have an 
ID attribute on a property in the XML serialization, (which apparently 
causes SIRPAC to create a reification for the corresponding statement).  An 
internal representation of this statement does not need to explicitly 
create the reification, but can use a structure similar to the one you suggest:

     (subject, predicate, object, statement-ID)

A similar approach can be taken to grouping RDF statements.  The XML 
serialization provides bagging that can be used to apply some set of 
statements to some other set of statements -- which is exactly the effect I 
saw provided by contexts.  So, the model can be extended to a 5-tuple:

     (subject, predicate, object, statement-ID, context)

where statements applied to a context are interpreted in the RDF model as 
being applied to the reification of all statements that belong to that 
context.  I can envisage a direct translation between this internal 
structure and the XML serialized form.  Thus everything relates to the RDF 
model without ever incurring the overhead of actually doing 
reification.  Maybe this is a small, obvious step to many, but it 
represents an important step forward for me.

There are still issues to resolve, but I feel as if I am very nearly ready 
to start working on a design for a system that represents and manipulates 
trust in RDF descriptions, leading to an actual implementation.

>NOTE2 :
>do you Graham are aware of SHOE's Claim model.
>It works quite the same way.

No, I'm not, though I have come across some SHOE papers but haven't really 
studied them.  I have a massive backlog of 'required' reading :-|

#g

------------
Graham Klyne
(GK@ACM.ORG)

Received on Tuesday, 27 June 2000 08:43:16 UTC