W3C home > Mailing lists > Public > semantic-web@w3.org > December 2005

Re: How will the semantic web emerge - OO languages

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 21 Dec 2005 18:00:48 +0100
Message-Id: <55EC3190-57B6-4CEB-BE8F-FBA1EBC8CAD4@bblfish.net>
Cc: "<tim.glover@bt.com>" <tim.glover@bt.com>, Semantic Web <semantic-web@w3.org>
To: Russell Duhon <fugu13@mac.com>


On 21 Dec 2005, at 17:35, Russell Duhon wrote:

> Oh, its often possible to inference types. However, OWL Full is  
> undecidable -- there may well be type inferences no reasoner can  
> compute, or possibly not compute in any reasonable amount of time.  
> Or then we could look at RDFS -- its perfectly possible for an RDFS  
> reasoner to deduce someone is both a man and a woman, since  
> disjointness is not allowed. It might still be useful to restrict  
> oneself in certain cases to RDFS, but that makes it much harder to  
> check up on RDF types making sense as intended (instead of just as  
> specified) -- a reasoner just won't be able to tell which types  
> apply to which instances exhaustively.
>
> Also, most things could be lots of types, even where we know that  
> makes little sense. I doubt many ontologies are going to express  
> disjointness between foaf:Person and dctype:MovingImage, but  
> there's no way any one instance is both. However, it would be  
> perfectly legal to define a dctype:MovingImage having a  
> foaf:firstName "Henry" in one's RDF absent such a specification.
>
> For certain ontologies, java beans are a reasonable model. For  
> others, though, with extremely flexible type systems, involving  
> type relations outside those that map directly onto the java type  
> system, its not so clear. Say it were possible for some instance to  
> be a foaf:Person from one ontology and a deo:God from another  
> ontology and a comic:Superhero from yet another, and there were no  
> subclass relationships among these. Heck, perhaps deo:God and  
> comic:Superhero both subclass from et:Nonhuman . While this isn't  
> absurd by any means, it does make denoting the instance's type in a  
> java bean complicated at best (I anticipate lots of interfaces ;-) ).

yes. My RDFHibernate library [1] works with interfaces that map onto  
an RDF database using dynamic proxies.

>
> I suspect, though, that ultimately it will be more useful to look  
> at RDF data in "slices" or from certain "perspectives" as fetched  
> by queries -- that is, we'll fetch nodes as the type we're  
> interested in looking at them in the context of, and not pay  
> attention to other possible types in most cases. In such cases,  
> java beans may well make sense. However, this is in some sense an  
> accommodation in adapting a less flexible type system (java's) to  
> RDF/RDFS/OWL's more flexible one.

That is what I have done.


> It will be interesting to see what some of the "more dynamic"  
> languages manage to do with metaclasses and the like to emulate RDF  
> typologies. Another potentially interesting approach would be to  
> model RDF as data, rather than OO objects, and just treat types as  
> another RDF property (albeit likely with some specialized utility  
> methods for dealing with). Prolog can do some very nifty stuff in  
> this vein.
>
> One thing I hope to see more and more of is the incorporation of  
> capabilities from logic programming into modern programming  
> languages. Successful recent languages have been OO and imperative  
> for the most part, with some functional capabilities. I think  
> greater logic capabilities will lead to better ability to deal with  
> RDF data.

Yes :-) That is indeed where things are going to become fun. Once you  
map your java beans onto an RDF database containing an inferencing  
engine then the distinction between procedural languages and  
inferencing languages starts to break down. Perhaps they were never  
as far apart as people thought they were.


> Russell
>
>
>
>
> On Dec 21, 2005, at 9:29 AM, Henry Story wrote:
>
>>
>> That is not such a big difference with OO computer languages  
>> really. In java if you know the type of something you may call the  
>> method, but the method may return null which is very similar. I  
>> have been working with such a system very happily for a year now,  
>> and have described an improvement [1] on my blog. Think of java  
>> beans as objects with relations.
>>
>> I don't know what you mean about it being "impossible" to claim  
>> that an entity does not have the right rdf type. In OWL you can  
>> specify that two classes are mutually exclusive. If you do, then  
>> you will know that if  you find something out there on the web  
>> that states that something belongs to both those sets, then you  
>> have a contradiction. Furthermore from the fact that a method is  
>> applied to an object you can deduce the type. So from
>>
>> [ foaf:firstName "Henry"].
>>
>> you can deduce
>>
>> [ foaf:firstName "Henry";
>>   rdf:type foaf:Person ].
>>
>> Henry
>>
>>
>>
>> [1] http://blogs.sun.com/roller/page/bblfish? 
>> entry=java_annotations_the_semantic_web
>>
>>
>>
>> On 21 Dec 2005, at 14:53, <tim.glover@bt.com> <tim.glover@bt.com>  
>> wrote:
>>> Yes. I think it is possibly misleading to compare rdf:type with  
>>> strong
>>> type systems in computer languages. That may have been the original
>>> intention but the ability to enforce types is in conflict with the
>>> requirement that all RDF statements are valid, and the RDF semantics
>>> supports the latter at the cost of the former. Within RDF it is
>>> impossible to claim that an entity does not have the right  
>>> rdf:type. And
>>> even if it does have the "right" rdf:type, it may in fact not  
>>> have any
>>> of the required properties. You COULD use rdf:type as a type  
>>> system -
>>> but it wouldn't be supported by the RDF semantics.
>>>
>>> The intuitive semantics of rdf:type is "if x has type y then it  
>>> makes
>>> sense to look at the values of these other properties of x (if  
>>> given)".
>>> I think that is often a useful piece of information.
>>>
>>>
Received on Wednesday, 21 December 2005 17:01:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 February 2013 14:24:52 GMT