Re: addressing requirements around daml:collection (rdfms-seq-representation)

>[...]
>
>>  RDF/xml has special syntax for containers, but experience
>>  trying to exploit it to come to intuitive conclusions
>>  has exposed problems. Take the class above... say
>>  Continent is the subject of that oneOf property.
>>  If we know
>>
>>     ex:Bob daml:differentIndividualFrom ex:Eurasia.
>>     ex:Bob daml:differentIndividualFrom ex:Africa.
>>     ex:Bob daml:differentIndividualFrom ex:North_America.
>>     ex:Bob daml:differentIndividualFrom ex:South_America.
>>     ex:Bob daml:differentIndividualFrom ex:Australia.
>>     ex:Bob daml:differentIndividualFrom ex:Antarctica.
>>
>>     ex:NotContinent daml:complementOf ex:Continent.
>>
>>  then we should be able to conclude
>>
>>     ex:Bob rdf:type ex:NotContinent.
>>
>>  Now this works perfectly well* when the oneOf claim
>>  is spelled out long-hand using first/rest/nil.

[To Dan:]
Well, that isn't clear. After all, it is RDF-legal to add some other 
rest/first/rest chains to the same bnodes, so the daml:list is just 
as dependent on a closed-world assumption as the RDF container syntax 
would be in this context. I bet that your (and Jos) code would break, 
or act unpredictably, if given a branching daml:list. (It would 
recurse down the first one it happened to find, but since they are in 
a bag this isn't well-defined by the syntax.) You can always take the 
line that having non-branching lists is a syntactic well-formedness 
requirement from DAML; but that is still extra to RDF, and then you 
could also impose a similar special DAML requirement onto some 
subclass of rdf:Bag. It's still a closed world assumption that goes 
beyond the strict RDF meaning.

>  >
>>  *[I should back this claim with running code,
>>  but in the interest of getting this and other
>>  stuff done today, I'm skipping that for now.
>>  I think Jos has the relevant code running.]
>
>I keep this as a nice test case
>and believe we can let this run
>
>>  But RDF/xml's collection syntax expands to these
>>  rdf:_1 rdf:_2 etc. triples, which don't say
>>  enough to come to the relevant conclusion
>>  without doing closed-world stuff.
>
>that alligns with our thoughts/experience too
>
>[...]
>
>>  On balance, I prefer parse-collection-STD right now.
>>  But I need to sleep on it or something to be sure.
>>  Other thoughts? Lynn? Jos? DaveB?
>
>well, I prefer parse-collection-STD too
>
>[[
>   * add parseType="collection" to RDF/xml;
>
>   * add rdf:first, rdf:rest, rdf:nil too.
>
>   * specify that parseType="collection"
>   is notation for first/rest/nil triples
>   ala daml:collection.
>]]
>
>having first/rest/nil triples is making it easiest
>to build entailment rules such as
>
>{ :rule10a } log:implies { ( ?x / ?b ) owl:item ?x } .
>{ :rule10b . ?b owl:item ?x } log:implies { ( ?a / ?b ) owl:item ?x } .
>
>{ :rule11a } log:implies { ( ( ) ?c ) :append ?c } .
>{ :rule11b . ( ?a ?b ) :append ?c } log:implies { ( ( ?x / ?a ) ?b ) 
>:append ( ?x / ?c ) } .

[To Jos:]
Shouldnt there be slashes in all these examples, eg shouldnt rule 11b be:

{ :rule11b . ( ?a / ?b ) :append ?c } log:implies { ( ( ?x / ?a ) / 
?b ) :append ( ?x / ?c ) } .

(If not, please explain the syntax a bit more.)

I don't follow what kind of assertion append: is supposed to be 
making here. (I thought append was a function...maybe I'm stuck in 
LISP, or something?)

( ( ?x / ?a ) ?b ) is a list whose first is (another) list, is that right??

>{ :rule12a } log:implies { ( ?a ( ?a / ?c ) ) :remove ?c } .
>{ :rule12b . ( ?a ?b ) :remove ?c } log:implies { ( ?a ( ?x / ?b ) ) 
>:remove ( ?x / ?c ) } .

?? How does that 'remove' work, exactly??

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 22 April 2002 18:35:44 UTC