Re: design decision regarding integer predicates

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