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

Re: Implementing statement grouping, contexts, quads and scopes (was: Re: Out of context, in context, out of subject ????)

From: Didier <didier@phpapp.org>
Date: Fri, 21 Jun 2002 17:03:50 +0200
Message-ID: <3D134056.20400@phpapp.org>
To: RDF Interest <www-rdf-interest@w3.org>, RDF Logic <www-rdf-logic@w3.org>

Jonathan wrote:

> The concept of "dark triples" as a layering option seems to be getting 
> a bit
> misunderstood. The essence of "dark" or "unasserted" triples is simply 
> that,
> from a technical perspective, it is difficult (some would indeed say
> impossible) to define a language such as OWL (and given the constraints
> placed on this language by the WebOnt charter etc.) in RDF if OWL is 
> to have
> the characteristics we desire, and RDF triples are all "truths".
>
Do you agree with that only OWL-specialized RDF processor may process 
OWL. That is the point of layering. Ok. So you may have a particular 
property (Statement->OWL_Context).
And you may define two different type of OWLContext (TBox and ABox as 
you say for instance). You are still in the RDF layer.

If another application (or processor) reads your WebOnt (or OWL) 
tripples, will it matter if some tripples are asserted or not as this 
processor do not 'understand' WebOnt semantics.

And then you define your language based on this core. This is how people 
work since two years. I can't see problems doing this for OWL too. If 
you don't mind reifying or even use the bag descriptions that use Alberto...

> So "unasserted triples" are a technical device that might, for example, be
> used to implement "contexts" and given the constraints placed on RDFCore's
> ability to modify _this version_ of RDF. I am sure that if RDF did have a
> native concept of contexts that there would be no need to have _another_
> discussion of "dark triples" as any such triples would instead be 
> placed in
> their own context. But that isn't an option for RDF as of June 2002, and
> WebOnt has a requirement to proceed with RDF _as it is today_.
>
Modifying RDF to add a specifity only for WebOnt. Is that layering ??????
Let us add something that everybody could use for their own applications.
Even for WebOnt home-extensions for instance.
We do have what we need in RDF, except a particular property (lets call 
it rdf:usedInContext)
SubPropertying will enable interoperability. Or even subclassing of the 
context classes.

> The problem "unasserted triples" is trying to solve is simply: How do we
> devise a model theory for OWL that is compatible with the model theory for
> RDF, possibly even an extension of the model theory for RDF in some 
> sense of
> the word, and avoids the introduction of paradoxes and other such 
> problems?
> Now will this same problem exist for every "new stuff" on the semantic 
> web?
> I can't say -- the hope is that if we do this correctly, not.
>
By using a wide-range property that you subproperty (let me create this 
word :) , sorry), you are still compatible with the RDF MT. I do agree 
that there will be ugly statements everywhere.

So, let me do an example proposition.

Let us add two core property to RDF:

rdf:usedInContext
   domain: Statement
   semantic: (quick and dirty explanation)
       << When a statement is marked with this property, the statement 
do not hold for the main context. A single statement may be used in 
multiple context by having multiple usedInContext properties >>

rdfs:subjectAllInstancesOf (ugly name sorry)
   ? subPropertyOf rdf:subject ?
   domain: Statement
   range: Class or Property
   semantic: (qade)
       << When a statement is marked with this property, the rdf:subject 
prop is not present in the statement. It is 'replaced' by all the 
instances of the class in range. (this is stolen from semantic networks) >>

Now a RDF snippet of part of the schema of an RDFS-MT extension. Here i 
choosed that i needed only two global (singleton) TBox and ABox context 
(So i use my 
'between-every-instances-of-a-class-to-an-instance-of-another' property).

<rdf:RDF xmlns:rdf="...rdf#" xmlns:rdfs="...rdfs#"
   xmlns="MySuperLanguage#">

<rdfs:Class rdf:ID="Class">
   <rdfs:subClassOf rdf:resource="...rdfs#Class"/>
</rdfs:Class>

<rdfs:Class rdf:ID="List"/>

<!-- ... -->

<rdfs:Class rdf:ID="Context">
<Context rdf:ID="Terminological"/>
<!-- Or Unasserted if you prefer -->

<rdf:Statement>
   <rdfs:subjectAllInstancesOf rdf:resource="#List"/>
   <rdfs:subjectAllInstancesOf rdf:resource="#first"/>
   <rdfs:subjectAllInstancesOf rdf:resource="#rest"/>
   <rdfs:subjectAllInstancesOf rdf:resource="#nil"/>
   <rdf:predicate rdf:resource="...rdf#usedInContext"/>
   <rdf:object rdf:resource="#Terminological"/>
</rdf:Statement>

</rdf:RDF>

Note that my solution in fact is very similar to your core type 
rdf:Unasserted. But i find the rdf:subjectAllInstancesOf semantic 
networks notation very better as it enables other applications to use 
the mechanism.

Remember that only OWL processor need to know that some statements 
should not be asserted.
Someone that do not understand OWL will not be fooled as he don't matter 
OWL definitions.

Remember also that in some uses and RDF processor may need to assert the 
OWL unasserted statements. Do you consider, for instance, that an editor 
is not an RDF processor ? What will be the policy dictated by the RDF 
MT. Should it expect all the different types of RDF processors and tell 
for each how statement are or not asserted ? Can you yet expect all of 
the RDF application types ???? No, IMHO this is application-type specific.

Last, this enables to create different assertionnal level, if you need 
it. This is why i tend to say that RDF should define one of those level. 
We will need many. I can yet count two of these: ontological terminology 
assertionnal level and a future rule terminology assertionnal level (in 
which ontological terminology statements are asserted, else how do you 
give/exchange rules to express their semantics ????)

In an other application i would have used different contexts for some or 
every of my instances.
As we do allready in fact. Do you like it ? Did i missed something ?

To conclude: Contexts used for all the instances of a class enables your 
kind of global layering. Contexts used for an individual enables 
contexts, grouping or however you want to call it.
The rdf:usedInContext property when used just denote that in a 
particular kind of application its subject holds for a particular 
semantic context.

Didier.
Received on Friday, 21 June 2002 11:04:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:54 GMT