W3C home > Mailing lists > Public > www-rdf-logic@w3.org > June 2002

RE: Implementing statement grouping, contexts, quads and scopes

From: Danny Ayers <danny666@virgilio.it>
Date: Thu, 27 Jun 2002 10:07:28 +0200
To: "RDF Logic" <www-rdf-logic@w3.org>
Message-ID: <EBEPLGMHCDOJJJPCFHEFIEOFGMAA.danny666@virgilio.it>

Hi guys,

Returning to a literal interpretation of the subject line, I'd appreciate a
bit of clarification - essentially, what's wrong with the approach to
statement grouping I give below. I'm sure this kind of approach has been
discussed at length before, but it's very difficult to remember what has
been suggested, let alone keep track of the consensus.

Ok, so let's say we have a couple of statements :

[urn:Sassi] --[a:hasSpecies]--> [a:cat]
[urn:Sambuca] --[a:hasSpecies]--> [a:cat]

So what do they mean? To begin with, they're assertions about a couple of
specific resources (Sassi & Sambuca) that make use of a given vocabulary
(a:). But to be able to do anything worthwhile with the statements we need
to know the context of their assertion - they are asserted in this email.
The url of the email in the archives (say email:765) can be used to identify
this. So an application can know the providence of the statements (the email
in the archives has a record of the sender), and we have a form of
grouping - the statements are both in the graph at the uri of this mail.

Years ago I overheard the police call in the name of someone they'd picked
up to get further information (wasn't me guv ;-). The response was concise :
known, not wanted. In the same fashion, if an application is aware of
email:765 then it is known, and the statements above are available. This
data can however remain 'not wanted'.

In practice, an implementation could contain two knowledge bases - one
'live' and one 'sandbox'. Each would contain a set of graphs, the difference
being that the 'sandbox' was passive and 'live' active. By passive here I
mean that it could be queried, but no logical inference would take place,
unlike in the live space. If the live space was asked about [urn:Sassi],
then it could query the sandbox, and retrieve the the statements above, both
of which would carry an association with email:765. The graph of email:765
could be examined to see if the data was wanted within the current terms of
the live space, e.g. if the sender was trusted. If so, it can be merged into
the live graph for inference. If not, the data is simply ignored. It might
be that this application rejects the vocabulary used (a:), say it includes
semantic extensions that this app doesn't understand.

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


Danny Ayers
<stuff> http://www.isacat.net </stuff>
Received on Thursday, 27 June 2002 04:15:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:38 UTC