W3C home > Mailing lists > Public > public-owl-dev@w3.org > January to March 2007

Re: n-ary datatypes

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 7 Feb 2007 17:42:16 +0000
Message-Id: <1B3B3DFD-2F41-41DC-8CEA-B842961C06E0@cs.man.ac.uk>
Cc: "Turner, David" <davidt@hp.com>, public-owl-dev@w3.org
To: Evren Sirin <evren@clarkparsia.com>

On 7 Feb 2007, at 13:00, Evren Sirin wrote:

> On 2/6/07 9:19 AM, Turner, David wrote:
>> Hi,
>>
>> I've recently started working with Jeremy Carroll at HP, initially
>> focussing on OWL 1.1. At the moment I'm reading through the specs,  
>> and I
>> have some questions about n-ary datatypes as implemented in OWL.
>> Fundamentally, I am having trouble seeing how n can be anything other
>> than 1.

[snip]
>> How, exactly, would one go about defining
>> the class of objects whose width is greater than their height?
>> Presumably the  intention is to have a datatype of arity two, whose
>> extension is the graph of the relation '>', but I cannot find the
>> appropriate syntax to define this.
> There is no proposed way to define these kind of datatypes. I don't  
> think it would be useful anyway because I don't see an easy way to  
> describe the semantics of such user-defined relations without  
> complicating the language. The alternative is to adopt a set of  
> built-in relations with predefined URIs, such as the ones described  
> in SWRL or SPARQL.
[snip]

Yep. That's likely what will happen. Now's a good time for people to  
pull together proposals. The sparql functions are likely candidates  
since implementations will want to support them for sparql filter  
support.

One could maybe have a limited shared user definable system. At the  
least, expressing type restricted versions of e.g., < is not to bad.

Otherwise, URIs + documentation + request to vendors. Most  
implementations make it pretty easy in principle, at least, to add  
such functions. It wouldn't be portable of course.

I know Alan Ruttenberg has gotten enthused about supporting  
javascript as a standard language for, roughly, procedural  
attachments. One could have something like that, though it's a bit  
more complex (and there are, obviously, security and implementation  
worries). I wouldn't want to try to tackle that now, but it's  
certainly something for implementors and interested parties to start  
experimenting with.

(There was a SWI-Prolog based system, a ways back, that let you  
"define" predicates by appeal to some arbitrary prolog  
code...called...RDFS explorer?)

Cheers,
Bijan.
Received on Wednesday, 7 February 2007 17:42:06 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:54 GMT