RE: Implementing statement grouping, contexts, quads and scopes

>> So essentially I'm suggesting two aspects to the context/grouping issue,
>> firstly that in the wild (on the web or otherwise available
>through public
>> interfaces) the triples exist implicitly as quads, i.e.
>>
>> [email:765] [urn:Sassi] [a:hasSpecies] [a:cat]
>>
>> and that whether or not triples get asserted remains entirely a local
>issue,
>> decided by the implementation.
>>
>> Putting this more strongly, we only really have two contexts - 'in the
>wild'
>> and 'in application X'.
>>
>
>You have collected some triples into sests, but to me a "quad" is
>individually identifiable.  In RDF, saying "about resource='email:765'"
>won't do this, and you can not say about "about='A and B'".

Good point, but I think this approach is still workable. The quads are
individually identifiable, though not by the traditional URI means, so this
does fall outside of RDF. But that's irrelevant really - I can work with RDF
on my computer, even though the operating system I'm using isn't built from
RDF. Internally I can create whatever unique identifier I like for the
information -

x(15) = {[email:765] [urn:Sassi] [a:hasSpecies] [a:cat]}

So if
>you had a
>processor that could do this, you could not express in RDF anything to
>distinguish the sandbox from the livebox.

Ah, I can't have made myself clear. The sandbox and the livebox are
logically distinct collections existing within an application.

>That might be OK, but I suspect that it will be useful to deal with more
>than one "color" of assertions in the future, which this mechanism cannot
>do.

What about my implementation being told that [email:765] is purple? In
livebox instance A, purple means 'trust implicitly' and in livebox instance
B purple means 'ignore any references to cats'. The colouring can be done
with RDF, the interpretation of the colouring is outside of the scope of
RDF.

Cheers,
DAnny.

Received on Thursday, 27 June 2002 07:45:01 UTC