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)
|