RE: RE: Discussion-Paper: A Logical Interpretation of RDF

[The referred paper: 
http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation.ps
http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation.pdf
http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation/index.html
]

Dear all,

in the following we try to answer the posts we received. Further
comments are still welcome (for example: do you think that this approach
may form the base for an "agreeable" formalization of the RDF model?)

The key propositions below are: 
- There are no anonyomus resources in the triple model. However, a
nested triple model may help to avoid mismatches between
graph/serialization and triple model.
- Too much "fixed" semantics is bad, but a minimal common denominator is
necessary.

Best regards,
     Wolfram and Reinhold


Brian McBride wrote:
:Reinhold,
:
:This paper was a pleasure to read!
:

Thanks.

:There were a few places where I couldn't reconcile what
:was written with my intutions:
:
:o (2) statement(s,p,o) => uri(s) ...
:
:  I'm not sure how to interpret uri(s).  RDF has anonymous
:  resources.  Is uri(s) true for such resources?  Is it
:  true for a reified statement?

There are no (in the strict sense) anonymous resources in the RDF triple
model. One may argue that in a "flat" (this will be explained below)
semantic network/triple model, it is (only) the NAME that gives an
entity its existence. Anonymous resources seem to be a by-product of
"convinient" RDF syntax - on first (and second?) sight this induces a
"mismatch" between (triple) model and (graphical/serialization) syntax.

Let us elaborate a bit on this: if one wants to make a statement 2 about
a statement 1, the easiest way to express this would be:

statement 2:  
	  [subject: [statement1], predicate: p2, object: o2]
with [statement 1] being a triple [s1,p1,o1].

(please, note that here triples are represented with [] and in the
sequence subject/predicate/object)

This can not be directly represented in the flat RDF triple model (here,
the statement 1 would indeed be "anonymous"). To our opinion, this
"nested" triple model (statement 1 can also contain deeper nested
triples and also, triples may occur at any position [is there a useful
example for having a statement/triple at the predicate position?])
would allow for a nice and straightforward model and would more closely
match the possibilities of the graphical model resp. the serialization.

But, ok, the triple model is "flat", so the following way seems
reasonable: give statement 1 a NAME so that this surrogate can be used
to refer to the initial statement in other statements, that is:

statement 1: [s1,p1,o1] hasName NAME  and 
statement 2:  [NAME, y, z]

Clearly, again the first "property" can not directly be expressed
(because it is essentially a 4-ary relation), so it needs to be
reconstructed by the well-known 4-triple reification of the RDF model.

[NAME,rdf:type,rdf:statement] [NAME,rdf:subject,s1] ...

Now, everything has been made "explicit" (that is, everything has a name
now, which is more that what was required in our original intention -
making a statement about a statement). Now, we can make a statement
about a NAME and the relation of the NAME to the original statement can
be reconstructed from the 4 reification triples (which
are necessary to recognize the name as being a representative for a
statement). This re-identification is done with our three "reifies"
rules. [Remark: If a reification is present, the reified object can not
be a Literal with our interpretation, well, well].

Now, a difficulty is that the "anonymity" of statement 1 is lost. This
would be no problem, if the RDF syntax would only allow for the use of
"explicit" reification, that is, a NAME would be given explicitly to
every representative of statements. But this is not the case, the syntax
makes use of "anonymous" resources/statements which (1) leaves
us with the problem of generating appropriate names (because names are
required, as has been shown above, in a "flat" triple model) and (2), in
consequence, induces something like an "expressiveness" mismatch
(because the natural representation of anonymous resources would require
a nested triple model) [QUESTION: so, should we change the
syntax or should we introduce a nested triple model or is this not
really a problem at all?]. Some related problem are briefly discussed
below in the answer to Stefan.

:
:o (5) lit(o) => instanceOf(o, rdfs_Literal)
:
:  I was curious why there is no equivalent 
:
:      res(o) => instanceOf(o, rdfs_Resource)
:

res(o) => instanceOf(o, rdfs_Resource) should not be asserted
"automatically" because if it is NOT INFERABLE, this allow the detection
of domain/range constraint violations. So, the question is more "why is
lit(o) => instanceOf(o, rdfs_Literal) required" ;) - part
of the answer is: because this seems to be a logically consistent way to
avoid a range constraint violation if comments or labels are present.
The problem behind this is the following: the range of labels and
comments is rdfs:Literal. The way that we chose (and this way seems, to
our humble opinion, to be a reasonable interpretation of the
RDF model documents) was to indentify a literal to be "something that is
not a (modeled) uri" - that is, something that does not occur in subject
or predicate position (it still can be a rfc-conform URI). Now, the
point is that if you would explicitly declare something to be a Literal
(x is of type Literal), this would immediately lead to
the conclusion that x is an (modeled) uri (because it occurs at a
subject position in a triple) -- which would reender the uri/lit rules
somewhat contradictory (which is, to our opinion, not really a problem
of the rules.). Hm, sounds still a little bit fuzzy but we hope that it
makes the motivation behind this rule(s) a little bit clearer.

:o In the discussion at the end of 3.2.4 you express some
:  concerns about the definition of subPropertyOf.  RDF
:  permits a resource to have the same property with more
:  than one value, i.e.
:
:       statement(S, P, O1) and statement(S, P, O2)
:
:  is just fine.  There is therefore no requirement that
:  Vsp has only one value.
:

Yup. Ok, than our comment on potential problems with subProperty will
only be interesting for people wanting to restrict this in their
schemata (so, in the next version, it will not be a general comment
anymore). By the way, Brian: Thanks to you, Stefan and William for the
input.



Stefan Kokkelink wrote:

[Quoted from Brian]
: There were a few places where I couldn't reconcile what
: was written with my intutions:
: 
: o (2) statement(s,p,o) => uri(s) ...
: 
:   I'm not sure how to interpret uri(s).  RDF has anonymous
:   resources.  Is uri(s) true for such resources?  

>That is exactly the point which I would like to be
>examined more closely: The representation of
>anonymous resources in an RDF (triple) model
>and operations that are allowed for the model.
>
>Consider the following example: 
>
> <Description bagID="XXX">
>    <dc:ceator>karl</dc:creator>
>  </Description>
>
>This results in the model:
>
> (genid0,dc:creator.'karl')
> (XXX,rdf:type,rdf:Bag)
> (XXX,rdf:_1,genid1)
> (genid1,rdf:type,rdf:Statement)
> (genid1,rdf:subject,genid0)
> (genid1,rdf:predicate,dc:creator)
> (genid1,rdf:object,'karl')
>
>Now I want to reify the statement
> (genid1,rdf:subject,genid0). No 
>problem in the triple model, simply 
>add the appropriate four statements
>for the reification.

>It is not possible to represent this new
>model in XML syntax !!! (At least if
>you want to preserve the anonymous resources,
>and I always thought there are good 
>reasons to do so).

Hm, interesting. By switching to the triple model, you NAMED a
representative for (genid0,dc:creator.'karl'), that is, the anonymity is
"lost" in the flat triple model (see answer above).

So, seeing it as a stepwise process, there is no problem anymore in
expressing the reification of (genid1,rdf:subject,genid0) in XML syntax
(´cause you now know the names genid1 and genid0 and can state the
triples explicitly in XML). But that is probably not what you wanted --
I guess you would like to add the reification directly to
the XML syntax above? This would not work, because you would have to
know the NAME of the anonymous resource/reification as a reference --
that is, you probably would have to model differently -- it may work to
make the bag resp. the reification explicit by not using the
bagid-construct, but explicit properties (_1, type, subject, predicate
...) and actively named resources.

[Two more short remarks: if we would try to automatically GENERATE
reifications from all given triples with a simple logic rule, this would
immediately end in an infinite recurrence. If the syntax would be
restricted to the explicit use of "named" reifications, no need for
automatic generation of names and reifications would be
present anymore. However, as Stefan says, there are probably a number of
good reasons for anonymous resources (as avoiding names if they are not
necessary) - shouldn't this be true for the triple model as well - so,
maybe, nested triples are a solution?]

>What does this mean: Is the new model not 
>correct? Are there statements in RDF that
>can't be reified? 

If you "hide" them with (syntactic) constructs leading to anonymity,
this seems to be a reasonable consequence. As suggested, making almost
everything explicit may help (however, "implicit" reifications of
descriptions seem to be intrinsically anonymous, so I am starting to get
a little bit nervous about your example).

>Or do anonymous resources
>not exist in the RDF data model?

(see above)

William Loughborough wrote:

[From our paper:]
>"The Resource Description Framework in one of its encodings is
>represented as a semantic network. Neither the semantics of the network
>representation nor the semantics of the underlying RDF model are
>formally defined. This may lead to different interpretations of the same
>semantic network by different users/agents and thus, the
>interoperability claimed does not seem to be justifiable with respect to
>semantics."

>WL: Not sure if what I'm responding is germane/applicable but "formally
>defined", "different interpretations", and "interoperability" may very
>well be blessings served up by the "de-centralization" of all this
>stuff. I think when Tim says (in relation to pre-RDF attempts at this
>stuff) "The problem with all such systems was that they were
>centralized." Just maybe the possibility of treating the "same semantic
>networks" differently is a boon to rather than a bane on
>interoperability? But then what do I know?

We probably should have elaborated a little bit more on the use of the
term "interpretation" above. The claim is somewhat like this: you are
still free to interpret the semantic net as you like, but with the
basic set of semantics, you are able to recognize some "elementary"
(formal) relations between the concepts of the semantic net. We agree
that trying to fix "too much" of semantics may not be
advantageous. However, fixing a small and accepted set of basic
"axioms" seems to be a necessity to allow the exploitation of the
benefits of "commonly understood" semantics. That is what we tried. By
the way: taking, for example, a full blown (Web) application, the
semantics that are captured by RDF (in its core) are indeed basic:
nothing is said about
processes/flows/transactions/transformations/operations etc. Clearly,
all this could be "syntactically" expressed in vocabularies/schematas
(as, for example, vocabularies for process descriptions [Frank
Pfeifer, for example, has prepared a working paper about encoding the
ARIS process modelling "language" in RDF]), but VERY LITTLE about the
"operational/processual" semantics is FIXED/expressible by the set of
basic semantic axioms provided by RDF. So, there is still a lot (too
much, maybe?) of freedom to interpret the intended "semantics" of an
RDF-based process description. This maybe considered good or bad. I
[W.], personally, would like to have something like a meta-schema
language that is based on clearly defined semantics (transaction
datalog, for example? Others would prefer algebraic specifications)
and that could be used to express virtually all Schema Languages that
are floating around (much like we tried to capture the RDF semantics
in simple datalog). This would not only allow to precisely compare the
intended "meanings" of the different approaches but it would also
provide a vehicle to "extend" schema languages flexibly -- that is,
the "little languages approach" that initially motivated some of the
work on XML (see, for exmaple, Matt Fuchs papers) by making the point
that the syntax of an application (domain) specific language should be
easily definable/extensible/interchangable could be extended to the
level of "semantics": by refering to a commonly available and accepted
set of "well-founded" semantic axioms, each one could easily define
his/her own SCHEMA language (and, based on this, his/her SCHEMATA and
SCHEMATA INSTANCES) and would still be "understood" (on the level of
the basic set of axioms used). In a sense, RDF is a step in this
direction - however, only supporting a limited set of possible
"semantic primitives"- and, because the formal semantic interpretation
is not part of the model and syntax, it is not, in the sense mentioned
above, extensible (as it has been mentioned in the note at the beginning
of the paper, we use logic to "define" the meaning of additional
constructs, such as "typed/prototyped containers", "monotonic
inheritance" for Reinhold's XWMF - this would, in the traditional RDF
context, only be possible in prose -- and, this, would ultimately bind
the applicability of XWMF models to specific implementations of XWMF
interpreters/tools). William, we hope this may clarify some of our
motivations.


Best regards,
     Wolfram and Reinhold

Received on Monday, 4 September 2000 08:42:16 UTC