RE: Discussion-Paper: A Logical Interpretation of RDF

> A second aspect comes from the formal model itself: 
> "1. There is a set called Resources. "

I don't recall the formal model saying that a resource must
have a uri.

> 
> A third aspect stems from the definition of triples (Section 5 again):
> "4.There is a set called Statements, each element of which is a triple
> of the form  {pred, sub, obj} ... sub is a resource ..."
> 
> Now, as we are in a text-based world of discourse (considering the
> triple model), we may conclude that we can not represent/distinct a
> member of a set other than by giving it a NAME (completely in 
> accordance
> with the Glossary definition.) - now, however, it starts to become
> tricky: if we have only one construct available to denote that an
> entities is a member of a set and if this construct is "give 
> the entity
> an IDENTIFIER/NAME" than there is no way to express that something is
> anonymous (i.e. "it has NO NAME") and is also member of the set. (ok,
> you could divide the namespace into "NAMES for NAMED RESOURCES" and
> "NAMES FOR UNNAMED RESOURCES", but this does not look to 
> plausible...).

I don't see a problem with that personally.  I tend to think of the
data model as primary, and the role of the other representations is
to represent the data model as best they can.  However, that is my
prejudice, and I'm pretty sure that was not what was in the collective
mind of the authors of RDF.

> So, in essence, a "thing" can only be used in a triple of the form
> {pred, sub, obj} if you can literally "write down" what it is 
> (i.e. give
> it a "NAME" - which does, in a sense, not only represent but "is" the
> thing to be indentified). 
> 
> Hm, well, sounds probably a bit too "philosophical". The 
> point I want to
> make is not to say that there are no anonymous resources in 
> the RDF data
> model, 

In which case, is uri(r) true for all resources in the data model?

> but that, in a flat triple model (and as triples are members of
> the set Statements and are, thus, not allowed to be inside of other
> triples according to the formal model - so the triples "have" to be
> flat) there is no (logically consistent) way to express 
> anonymity. And,
> writing this, I have to say that this, in a sense, also violates the
> postulated equivalence of the above mentioned three representations of
> the data model (what a name, by the way, data model ;).

I would agree with this conclusion.  Identifying this, and any other
similar issues, is a valuable contribution to this community.

> 
> This becomes relevant in a few places of Section 6, like:
> "Each propertyElt E contained by a Description element results in the
> creation of a triple {p,r,v} where: ... 2. r is the resource whose
> identifier is given by the value of the about attribute of the
> Description or a new resource whose identifier is the value of the ID
> attribute of the Description, if present; ELSE THE RESOURCE HAS NO
> IDENTIFIER."

Hmmm.  Yes I handn't spotted that one.

> 
> Ok, but, in the triple model, r does not represent anything already
> magically known in the triple model - no, the resource 
> "behind" r IS its
> IDENTIFIER. (In the graphical model, it is trivial to make a 
> seperation
> between named and unnamed resources -- simply leave the name 
> out of the
> oval - but this option is not present in the triple model - 
> so, what do
> you replace r for?).

Which model is primary?  There needs to be a definitive model, and I have
chosen, for me at least, that its the data model.  Of course, if
all the models were equivalent, then there wouldn't be a problem.
But as you have pointed, under at least some interpretations of the
spec, they are not.

> 
> However, some will find this discussion probably rather 
> academic because
> the "practical" solution of Parsers is to GENERATE names for 
> "anonymous"
> resources -- this way, a resource can be (represented) in the triple
> model. Nevertheless, as we tried to argue in the last email, the
> necessities for generating names could be diminished if a 
> nested triple
> model would be used.

Not all parsers do that.  RDFFilter does not.  Those that do don't
all do it the same way.  Are these generated names URI's?  My interest
is in API's that applications, including parsers, can use to generate
implementations of RDF models - what contrainsts should such API's
enforce.  For example, the XML serialization cannot represent  an
anonymous resource which is the object of more than one statement.
Does that mean that an application should not be able to create
such a model directly using an API or does the syntax need a fix
to enable it to represent such models?

Yes, these discussions can get a bit anal, but there are some very 
practical implications of the outcome.  I need to know what my API
should do and the spec currently, does not give me a clear answer.

My preference would be to see such issues identified as issues, and
then for some resolution be developed on the basis of what is the 
'best' resolution, not on reading the entrails of the spec.

> Prolog-Parser). Ideally,
> this would end in an commonly accepted TRANSFORMATION GRAMMAR (Jan's
> grammatical rules could be a good start).

Now that sounds like a good idea.

> 
> So, my answer is: if a "tripleization" makes the resource-type
> information in the syntax above explicit, no violation would be
> detected. If it will not be made explicit, one could consider this an
> incomplete tripleization and a violation will (reasonably) detected.
> 
> One may, however, argue, that everything in subject or predicate
> position (and everything not a literal in object position) should
> "automatically" be considered to be an instance of 
> rdf:Resource - if you
> would like to have it this way (and you seem to want it ;), 
> the rule you
> suggested would be a nice solution (seems reasonable to me, we should
> probably add it).

> 
> :If so, I disagree.  Anything identified by a URI
> :is a resource and even though there are no specific type
> :properties, no constraint violation exists.
> :
> 
> Maybe it should read: anything identified by a URI can be a 
> resource? I
> say this because only if "something" is part of the model, it 
> becomes a
> resource in the model context. So, only if the URI is "recognized" (it
> has to be in subject or predicate position somewhere - which 
> is probably
> not in accordance to "declaring" an object explicitly as 
> resource as is
> described in the RDF M&S document, oh well, if the type-resource
> relationship would be made explicit, this would work again ;) as
> something that identifies a resource (in the model), it becomes an
> identifier (uri(x) predicate in our rules) for a "modeled" 
> resource. So,
> our statement would be "every x that makes the (logic) 
> predicate uri(x)
> true is considered to be a resource.

How about, if x is the subject of a statement, its a resource,
and if its the object of a statement, and not a literal, then its
a resource.  That would deal with anon resources as well.


Brian

Received on Tuesday, 5 September 2000 02:19:04 UTC