[Top] [All Lists]

Re: [ontolog-forum] Next steps in using ontologies as standards

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Chris Mungall <cjm@xxxxxxxxxxxxxxx>
Date: Tue, 20 Jan 2009 14:55:20 -0800
Message-id: <9151BEC1-B72A-4DA4-8AE9-8715B576C46A@xxxxxxxxxxxxxxx>

On Jan 20, 2009, at 12:15 PM, Pat Hayes wrote:    (01)

>> PH> RDF syntax is in fact (that is, definitively according to the
>>> specs) defined abstractly, as a graph.
>> I certainly like graphs.  But see the mistakes by Guha and Bray.
>> PH> [RDF and OWL] represent a viable approach to the problem they
>>> were designed for, which was to be machine2machine communication
>>> notations for the semantic web...
>> They're viable in the same sense that a duckbilled platypus is  
>> viable.
>> But the world had developed far better technologies many years ago,
>> implemented them in relational databases, integrated them with the
>> WWW,
>> and taught them to programmers around the world.
> They weren't integrated with the WWW in the required sense. Its one
> thing to be interfaced with the WWW, its something else altogether to
> be the interface for everything else. For example, the Web is, like it
> or not, built on XML technology. No interchange format which ignores
> or tries to replace XML has a snowball's chance of getting adopted.
> I agree that it might have been a good idea to have allowed n-tuples
> from the beginning. This was even being discussed by the RDF WG for a
> while. But there were many problems and complications that would have
> introduced, the implementors loved triple store technology (which
> still runs way faster than DB tables when you have a large enough RAM,
> and we are in the 64-bit address ranges now)    (02)

Do you have a citation for this? Is this comparing in-memory RDBs with  
in-memory triplestores? Surely it depends on what you're doing, what  
level of expressivity you need, if you're using custom datatypes, the  
size of your database, the extent to which recursive predicates are  
used etc.    (03)

I find the preference for triplestores puzzling. SPARQL doesn't  
provide aggregate operators or the ability to construct intensional  
predicates (views) using standard boolean operators. This pretty much  
kills it for serious scientific work as far as I'm concerned.    (04)

> and I didn't feel (and
> still don't feel) that this is a serious problem, as it is so simple
> to encode a n-tuple as n triples.    (05)

Well, yes and no. The problem is that as soon as you reify n-ary  
relations, you lose the ability to apply unary property constructs  
such as transitivity and role chains, at least using the constructs  
given to you in the languages which are typically layered on to RDF.  
You can perhaps recapitulate some of these in SWRL by essentially  
defining your own n-ary OWL but this is hard and kind of defeats the  
point of staying within a limited subset.    (06)

If it is so simple, then why not allow n-ary relations in the language  
and have the translation done automatically (or at least semi- 
automatically, giving the user the option of which pattern to use)?  
Forcing humans to apply the n-ary relations pattern (and then having  
tools perform the reverse transform prior to presenting to end-users)  
seems kind of backwards.    (07)

I suspect the term "simple" here applies to those of us versed in KR  
modeling and logic. For the intended users of these languages -  
scientific domain experts for example -it's not quite so simple.    (08)

it's ironic that the majority of SPARQL queries return n-ary  
relations, rather than graphs. However, those n-ary relations cannot  
then be used in subsequent queries - a massive limitation.    (09)

On the other hand, the vast majority of predicates in relational  
systems to have higher arity than they need to. The binary predicate  
constraint forces a normalized design, whether you like it or not. The  
problem is with the minority of predicates for which 3 or more  
arguments make for a simpler design.    (010)

Hopefully Common Logic will gain more traction..    (011)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (012)

<Prev in Thread] Current Thread [Next in Thread>