- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Mon, 23 Apr 2007 18:03:45 +0100
- To: Sandro Hawke <sandro@w3.org>
- Cc: semantic-web@w3.org
On 23 Apr 2007, at 16:59, Sandro Hawke wrote: [snip] >> They are ordered but that order is neither really "semantic" nor is >> it intention revealing. For example, the canonical use of rdf:List is >> in OWL syntax where it represents an unordered collection (at some >> level). >> >> For example, I can add, without difficulty, the following statement >> to your turtle: >> p:Charles f:children ( p:Harry p:William ). > > Not if f:children was an owl:FunctionalProperty. I presumed we were sticking inside RDFS. > I didn't get into > that, but I would expect one would usually want it to be. That feels much more contorted to me. It might be useful for mirroring, e.g., UML stereotypes, but there I think I'd want a better theory of lists. >> But more to the point, even if they *are* ordered, and you exploit >> that order, it's not a good way to achieve the *modeling* of the >> ordering in question. Usually there are many orderings (age, grades, >> number of hair follicles, height). The *significance* of the >> ordering above is pretty clearly age, but then why not model that? In >> both cases, *recognizing* the order comes from outside. >> >> This is an old point from relational database design. > > In general, I agree with this principle, but what about > > (1) When the ordering is only significant in the context of the > relationship, such as with the words of a sentence, or the > slides > in a particular slideshow (which are arranged to make a > rhetorical > point)....? What about them? First, these, at least in this form, don't seem like natural things to model in RDF or OWL. Second, we'd need to see more of this modeling and what we want to get out of it (i.e., the application purpose). I'd expect that if I were modeling *sentences* that I'd want a parse tree. If I were going to model the ordering of a slideshow, I might come up with some sort of ordering structure (which I take it to be the point, rather than using rdf:List per se). This is just a special case of either having a natural ordering (i.e., position numbers) or a partonomic structure (of which a linear one is one sort). > (2) When users want quick results -- they don't want to think > through > the semantics behind the ordering -- they just know what > order the > items belong in. It's hard to see how this gets elevated into a *design principle*. I guess I don't have huge preferences for *how* one crappily models (or how one fights against the way a language is designed)! > ? > >>> By "exhaustive", just to be clear, I mean that using Style 2 one can >>> define "children" such that when we list Charles' children we are >>> also >>> saying these are his *only* children. >> >> But you aren't saying that. > > That's what users seem to me ^^^^^^^^^^^ > to be saying when they (including the OWL > RDF syntax) are using rdf:List. I understand it's not always > formally > or even informally stated. ^^^^^^^^^^^^^^^ But sometimes, often, it's *wrong*. That's *not* what they're saying. >> Add: >> >> p:Charles f:children ( p:Janice ). >> >> Who are p:Charles' children? > > I believe my semantics, in both English and FOL, would render that > merged graph inconsistent. ? Sorry, I guess I'm not really responding to future or idiosyncratic features or meanings, just what's actually in the current specs. I discourage the plural pattern using rdf:List because it's not well supported in RDF/OWL and doesn't seem to be all that great a modeling style *per se* in FOL for many things. It's a bit datastructurey. If you consider how you might go on to try to create classes which Charles would fall into wrt his children, I think things fall apart rather quickly. [snip] > Perhaps I wasn't clear. I was assuming > > f:ParentWithTwoKids rdfs:subClassOf [a owl:Restriction; > owl:onProperty f:child; > owl:cardinality "2"]. > > so that we wouldn't have to repeat the Restriction triples for each > such > parent. But I get your point that you don't have to name them, since > naming implies a kind of advance planning that isn't actually needed > here. Right. I didn't see how to understand your point *except* as about introducing unfortunate overhead. > So it's easy enough to state that one is providing exhaustive > information. Yep. Either way. Cheers, Bijan.
Received on Monday, 23 April 2007 17:02:57 UTC