Re: RDF model revisited, or: How to make the most out of Reifications and Containers

Graham,
 
Graham Klyne wrote:
>
> I think your approach is constructive, and consistent with (e.g.) the
> discussion that Pat and I have had about the relationship between syntax
> and semantics.
>

Thanks. Reading your last discussion with Pat was indeed very
interesting. 

> I think the assumptions need closer examination;  your proposed approach
> means that additional assertions that reference a container- or
> reificant-resource are not possible in the extended model (or they become
> detached from the container/statement when your constructive proof of your
> proposition 2 is applied).  I think this does represent a change in the RDF
> model, but one which might be considered beneficial.
>
> Concerning your assumption 2, it is not clear to me when you say "p relates
> s to (r1,...,rn)"  {{{NOTE:  I think that's what you meant, but you
> wrote  "[r1,...,rn]".}}} 

Yup. My fault. Reinhold had spotted that one but I failed to correct it
(next version).

> whether you mean p relates to the container, or p
> relates to the members of the container.  In existing RDF, this would apply
> to the container.

Container. Should be made clearer. (Ok: in RDF, the container seems to
be its name, in the extended model, the container is the list of
resources/statements/lists. Is there a proper name for the actual
"content" of a container in RDF?)

>
> Test case (using an obviously RDF-equivalent subset of N3 as an easier syntax):
>
>    ex:c1 a rdf:Bag ;
>          rdf:_1 ex:m1 ;
>          rdf:_2 ex:m2 ;
>          ex:prop ex:val1.
>
>    ex:c2 a rdf:Seq ;
>          rdf:_1 ex:m1 ;
>          rdf:_2 ex:m2 ;
>          ex:prop ex:val2.
>
>    ex:c1 ex:prop ex:val3.
>
> This defines *two* containers (one rdf:Bag and one rdf:Seq) with different
> properties.
> Using your proposed approach (to crudely extend the N3 syntax used above) I
> guess this might be achieved with something like:
>
>    ( ex:m1, ex:m2 ) a rdf:Bag.
>    ( ex:m1, ex:m2 ) a rdf:Seq.
>
> The problem I see comes when one wants to *separately* make an assertion
> about one of those collections; i.e. how to say
>
>    
>
> The resource 'ex:c1' that "stands for" the container has been removed in
> the extended model.  (I suppose you would say that the resource is still
> there, but the syntactic designator to which properties can be applied has
> been elided.)
>

1. The problem with ex:c1 ex:prop ex:val3. is that it is not clear in
RDF (at least not to me) if val3 (a) applies to c1 (for example
expressing that the "name" c1 has_been_introduced by val3) or (b) to
what c1 represents (ie, it is a quality of the list of resources that
are represented by c1). There is no way to distinguish this is RDF on a
"syntactic" level (one could attach this information to the property
that is used: does ex:prop apply to the "resource" c1 or the represented
list, which would require new (and useful) mechanisms at schema level).
So, we simply decided (with assumption 2) that we always interpret
containers in RDF as being used as in (b). As long as there is no way to
distinguish this cleanly in RDF, I can not think of a general way of
transforming it into something more useful in the extended model. 


2. If (a) was intended, the type of the container doesn't matter. If (b)
was intended, it doesn't matter either because the type of the container
can not be given any relevance in RDFS with its current "semantic"
instruments. What would be required is do be able to specify the
intented behaviour of ex:prop depending on the container-type of the
represented container. This is not possible. That is to say that the
information that is lost above can not be used in current RDF/RDFS
anyway.  (If the instruments would be there to meaningfully distinguish
the potentially different consequences of attaching a property to a
container of seq/bag/alt-type, we could react accordingly and try to
find a suitable conversion to the extended model).


[Allow a further remarks: I do not think that this kind of "type"
information (Seq, Bag, Alt) belongs to the level of structures. Lists is
all that is needed to "represent" all those "types". I do not even think
that it is useful to attach such information to a list on a schema
level, because I think that this should be a quality of the property:
property A may interpret a list L as a sequence, property B as a bag,
property c as a Alt - depending on the definition of the properties -
and all work "cleanly" on lists]


You are clearly right in that not every "thinkable" (and useful) use of
RDF constructs is meaningfully covered by the mapping of the models.
However, I hope that I succeeded in pointing out that also not every
"thinkable" use of RDF constrcuts has a meaningful, unambigous, and
expressible (not to ask for precise) interpretation in RDF/RDFS...and,
maybe, the above debate point out one of the cases where this may hurt?


> ** As I write, I think I've finally spotted the root of what's bothering me:
> Your extended model is unclear about whether multiple occurrences of, say,
> ( ex:m1, ex:m2 ) indicate the same resource of different ones.  Section 2
> seems to allow distinct occurrences to represent distinct resources R.  But
> the proof of proposition 1, footnote 5, says "a new symbol for each
> subexpression t that is not already represented in the flat model", which
> suggests that a single resource is generated for any given collection.  

It was not intended to be unclear - sorry. There will be only one name
per subexpression, ie. multiple occurences can not be distinguished
using "names" (only from their "usage context").

> The
> proof of proposition 2, it is not clear to me whether or not "the
> expression <sigma> which r represents" is repeated if multiple resources
> stamnd for equivalent expressions.

Equivalent probably reads: indentic? The procedures are: remove every
reificant or "container name" and replace by the statement or the
"container content" (RDF-to-Extended) and  "introduce precisely one name
for each subexpression" (ie. multiple occurences of, say [S1,P1,O1] will
all have the same name in the flat model. (In the XRDF implementation of
the "flatenizer", I introduced different names for each occurence (even
names that reflected that position in the surrounding triple), is that a
better idea? I am not sure. I think that the semantics for the extended
model should have a means to express meaning depending on the contextual
"position" of a triple/container (coming from list and nested triples to
order is straightforward, one may even be tempted to postulate that
every extended model should be a list...ok, ok, I know, you like the
aspect that order is not heavily used in RDF...I don't like it too much,
I have to admit, because, once you have order information (and a
document has some form of intrinsic order, hasn't it? And is this not
all about "documents/protocol streams" on the Web, finally?), it may
make life a little bit easier, because you can identify things with
their position and don't have to use a hell lot of names - and you can
always leave the order information unused, if you don't need it (Ok one
could use order information already - you could "write" RDF models about
RDF documents and use some XPointer-URI's to say something about things
in the initial RDF document at certain positions, but that is not really
cleanly accessible on Schema level ;). It may be interesting to exploit
the structure for the definition of properties, for example, one may
create properties that use some form of "relative" addressing, like
[[(m1,m2),type,Bag],SubjectOfEmbeddedTripleHasValue,ex:val3] (to be
properly defined on a semantic level), which may have some useful
applications etc. But this is another story [Sorry for the digression]).

Allow a final question: Do you (any reader) think that the
nested_triples/lists stuff is a "workable" or even "preferable"
alternative to flat triples/reification/containers? Or do you consider
this as a "dead end"?


Wolfram

Received on Friday, 1 June 2001 12:14:39 UTC