Re: UPDATE: longer version of layering document

[...]

>> Sure.
>> Having :s :p [ :a :b ] . (which is N3's way
>> to write :s :p _:o . _:o :a :b)
>> then there is *no* way to point to that [ :a :b ].
>> You can however use that [ :a :b ] ``by-value'' i.e.
>> make a ``copy'' of [ :a :b ] e.g. :x :y [ :a :b ] .
>> (after all, bnodes are untidy anyway)
>
>Sure you *can* do this, but what is the point?  Are you saying that Bnodes
>should only have one incoming edge?

exactly
as I said yesterday, to resolve your paradoxes
[[
  also that example at the end of 4.2 contains
  a cycle with nothing but blank nodes
  and that is indeed paradoxical, but it
  can be avoided if we stick with
  the idea of having blank nodes ``by-value''
  and not ``by-reference'' (after all, they
  have no identifier, just maybe a label,
  but that is *not* an identifier)
]]

>If so, then you should speak *very* quickly to the RDF Core WG.

I do that daily ;-)

> I'm only using the facilities available in RDF.

I understand that

>> So [the acyclic and?] cyclic cases are ruled out that

with acyclic I meant such cases as
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0013.html
i.e. a Bag of reified statements
but that's of course an issue on it's own ;-)

>> way and you basically get a ``tree'' where
>> the leaves are urirefs or literals and the
>> bnodes are ``branches''.
>> That's the way we do things in Euler, and believe
>> me, we have no trouble with such cases.
>
>Well then Euler cannot handle all of RDF.  Are you sure you want this?

I think so (but my opinion is not important,
we have to find rough consensus together)

>> (Remembering the
>> :John a [ owl:intersectionOf ( :Student :Person ) ] .
>> entailing
>> :John a [ owl:intersectionOf ( :Person :Student ) ] .
>> using
>> http://www.agfa.com/w3c/euler/owl-rules.n3)
>
>
>The problem is that we have an already-exisiting formalism to deal with.
>(Yes, of course, it is under change, but only in certain, limited ways.)
>If our solution to problems posed by characteristics of that formalism is
>to change the formalism, then we need to be very clear as to what changes
>we want to pose, why we want to pose them, and what result we want.

right, I fully agree


>As an aside, I believe that I have made my views on what changes I want to
>RDF and RDFS clear.  (For a recap, with some additions, see below.)  How
>about let's propose them to the RDF Core WG?
>
>
>> --
>> Jos
>
>Peter F. Patel-Schneider
>
>PS:  Here are (most of) my proposed changes to RDF:
>1/ Move rdf:type out of the theory into the metatheory
>2/ Remove reification.
>3/ Remove containers.
>4/ Remove several syntax abbreviations.
>I want 2 and 3 removed because they don't have appropriate meaning. I want
>4 removed because it interferes with the correspondence between RDF and
>XML. I want 1 moved because it causes semantic paradoxes in more-powerful
>formalisms.

1/ could you clarify? i.e. how would a theory a la
   http://www.agfa.com/w3c/euler/rdfs-rules.n3 be impacted?
2/ RDFCore should clarify e.g. http://www.agfa.com/w3c/euler/rdfr-theory.n3
2/ RDFCore should clarify
4/ such as?

--
Jos

Received on Saturday, 9 February 2002 09:42:25 UTC