- From: Frank Manola <fmanola@acm.org>
- Date: Fri, 28 Sep 2007 13:24:18 -0400
- To: Garret Wilson <garret@globalmentor.com>
- Cc: Semantic Web <semantic-web@w3.org>
Garret-- Responses below. --Frank On Sep 27, 2007, at 11:35 AM, Garret Wilson wrote: > Frank, > > Frank Manola wrote: >> >> This is pretty much off the top of my head, but I'd be >> uncomfortable with a design that simply uses a number as a >> predicate, because then the predicate seems to have little or no >> meaning by itself. Instead, it has to borrow much of its meaning >> (that it represents a position in an array) from the fact that >> it's being applied to an array. If I just had the number by >> itself, I'd know practically nothing about the meaning of the >> predicate. Using a number like this makes more sense in an OO- >> like model, where properties are associated with particular object >> classes (and so the class is part of the semantics of the >> property) than in a more relational model like RDF. However, it >> could certainly be made to work. If it were me, though, I'd at >> least try to distinguish the ordinal characteristics of the >> predicate (i.e., that the predicate represents a position in some >> structure). > > Yeah, those were the sort of bad feelings I had originally and > which made me raise this question. > > Let's say (again in the abstract, outside of any particular > framework) that we have two types: MyIntegerType and MyOrdinalType, > where for each MyIntegerType instance (e.g. 5) you have a > corresponding MyOrdinalType instance (e.g. 5th). > > 1. Would you have less semantic qualms about using instances of > MyOrdinalType as a predicate of an array class? Yes, I would have fewer qualms. If I understand what you're saying, you're creating a type whose instances represent a set of ordinal positions (first, second, etc.). So you could (say) have a triple that means something like "A isFifthElementOf B" (or "A hasFifthElement B" depending on which way you want to read the predicates; I'm assuming you'd write instances of the type, rather than "isFifthElementof"). > > 2. Would it be appropriate for MyOrdinalType to be a subclass of > MyIntegerType? I'm not so sure about that one. It's been a long time since abstract algebra! > > This also has some interesting ramifications---MyOrdinalType would > also be a subclass of some sort of PropertyType, but MyIntegerType > would not! > > 3. Lastly, let's say that we have some predicate called "order", > specifying the order of the object in the subject resource. Would > the object of this "order" predicate be of type MyIntegerType or > MyOrdinalType? > > My opinion is that the object of an "order" predicate would be > MyIntegerType. This is because if A->contains->B->order-> > (MyIntegerType), this could imply that A->(MyOrdinalType)->B. In > other words, again, MyOrdinalType is always a property, and > MyIntegerType is never a property. It seems to work. What do you > think? You're two examples don't seem to agree exactly (comment #3 suggests a structure of ex:subject ex:order ex:object, while the second one has A->contains->B->order->(MyIntegerType)), but I think I agree. In either case, you strictly wouldn't need to use an ordinal as the value of the predicate because the "order" predicate provides its own semantics that its value represents a position. On the other hand, you could require an ordinal for better type checking. In that respect, it's like a lot of predicates: e.g., you could use both a predicate like "ex:zipCode" and still have a specific zip code datatype for the values. Depends on stuff like where you want the validity checking to take place. > > Best, > > Garret > >> >> >> On Sep 26, 2007, at 2:55 PM, Garret Wilson wrote: >> >>> >>> In case no one understood my question (hence no replied), let me >>> rephrase it. >>> >>> In most instances I think of the integer 5 as being a cardinal >>> number. If I use the integer 5 as a predicate to an array >>> resource to indicate the fifth element, I'm using the integer 5, >>> not as a cardinal number, but as an ordinal number. Is this a >>> semantic discrepancy I should be worried about? >>> >>> Garret >>
Received on Friday, 28 September 2007 17:24:37 UTC