Re: Clarifications needed for the Collection construct (with CR)

(Frank, see @@)

>Hi,
>contains also a comment to: Issue #hendler-01 literals in
>rdf:parseType="Collection"
>
>... thanks Pat for your input.

Quick comments inserted below.

>
>>
>>  >genID:1  rdf:type  rdf:List .
>>  >genID:1  rdf:first  ex:aaa .
>>  >genID:1  rdf:first  ex:bbb .
>>  >genID:1  rdf:rest  ex:ccc .
>>  >genID:1  rdf:rest  genID:2 .
>>  >genID:2  rdf:type  rdf:List .
>>  >genID:1  rdf:rest  rdf:nil .
>>  >
>>  >The question that arises, does it make any sense?
>>
>>  Yes, it does. If one were to assume (as for example OWL does) that
>>  rdf:first was a functional (unique-valued) property, then this graph
>>  would entail that ex:aaa = ex:bbb = ex:ccc (in OWL, this could be
>>  expressed by owl:sameIndividualAs).
>>
>>  Since neither equality nor functionality can be expressed in RDFS,
>>  this constraint doesn't amount to much in the RDF model theory; but
>>  as the spec points out, a semantic extension  (like OWL) may impose
>>  further conditions on the RDF collection vocabulary.
>
>OK, I think this entailment (ex:aaa = ex:bbb = ex:ccc ) should be stated
>in RDF Semantics (3.2.3) and in the RDF Primer too!

I disagree, for a reason which is partly technical. We COULD do this, 
but if we did, then we would have defined a very peculiar entity, 
which would be a logic which was inherently unable to capture its own 
semantics. This is because this constraint cannot itself be expressed 
in RDF or RDFS; so it is impossible to capture its intent by any kind 
of RDF/S inference rule or axiom.  The semantics document doesn't 
just give a model theory: it also provides proof rules and axioms 
which exactly 'capture' the model theory, in the very crisp sense 
represented by the closure lemmas in the later sections. If we were 
to impose plausible-sounding but inexpressible semantic conditions, 
this kind of semantic/syntactic correspondence would be impossible.

This is not just a matter of theoretical elegance, by the way. In a 
strong pragmatic sense, the main purpose of a model theory is to 
provide a foundation for useable inference systems. It is the rules 
which are of actual use in operational software, not the model theory 
directly. So to have a model theory which CANNOT be made to conform 
to a set of rules is like pouring a foundation which it is impossible 
to erect a useful building on.


>Having the mail from this archive: Issue #hendler-01 literals in
>rdf:parseType="Collection"
>in mind, it might cause additional problems. It then can result in something
>like:
>"Hello World" = ex:aaa
>A literal being equal to a resource!?!

I have no problem with that, myself. In the RDF model theory, all 
literals are resources in any case. Everything is a resource.

....

>  > >As shown there can be more than one rdf:rest, more than one rdf:first and
>>  >even the existence of rdf:nil as the terminating object is nowhere
>forced.
>>
>>  But how could it be forced? RDF graphs cannot have global conditions
>>  imposed on them by the spec, since they may be formed in real time,
>>  by rather dumb software which simply collects triples from other
>>  places and mixes them together. RDF does not undertake to impose any
>>  global syntactic wellformedness conditions on graphs: the 'largest'
>  > syntactic unit in RDF is the triple, and a graph is simply a set of
>>  triples. The intention of the 'list' vocabulary however is that *if*
>>  the lists are 'well-formed' *then* they denote an appropriate
>>  sequence of items.
>>
>
>But there are already such conditions. E.g., a node with
>rdf:type=rdf:Statement must
>have exactly one connection by rdf:subject, rdf:object and rdf:predicate.

No, that is not correct. This is not an condition on the RDF syntax. 
You can write an RDF graph that 'misuses' the reification vocabulary 
just as easily as one that misuses the other vocabularies.

...

>  > >
>>  >The effect is that by entering a non-blank node someone could enter also
>>  >to the collection construct elements from outside. This means without
>  > >any restrictions this construct is not fixed!
>>
>>  Right, it is not. Nothing is 'fixed' in this sense in RDF. Bear in
>>  mind - its a centrally important point - that the RDF/XML notation is
>>  *only* an XML serialization syntax for the RDF graph. Any extra
>>  structure you might feel is 'natural' in the XML (eg the assumption
>>  that the listed elements of a container are the full complement of
>>  the members) is not significant in the RDF if it is not made explicit
>>  in the RDF graph itself. The relatively 'tight' syntactic form of the
>>  XML is potentially misleading if this point is not kept in mind.
>>
>
>It should be stated in the RDF Primer!

@@
I believe it is stated there. I will forward this message to the 
Primer editor in any case.

.....

>
>Since there can be multiple or none rdf:nil appear in a collection, it might
>be more
>effective to have an extra property denoting the length of a collection or
>container!?!

We did consider that option, but that requires RDF to incorporate a 
built-in notation for referring to numbers, which introduces many 
other complications. And bear in mind that the 'list' style was 
explicitly requested by another working group.

Pat Hayes
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Wednesday, 26 February 2003 16:17:55 UTC