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

Re: How will the semantic web emerge - OO languages

From: Russell Duhon <fugu13@mac.com>
Date: Wed, 21 Dec 2005 11:35:06 -0500
Message-Id: <BDEF2405-3CF8-4D56-A3F7-9A00E82241C7@mac.com>
Cc: "<tim.glover@bt.com>" <tim.glover@bt.com>, Semantic Web <semantic-web@w3.org>
To: Henry Story <henry.story@bblfish.net>
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 ;-) ).

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.

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.


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.
>> -----Original Message-----
>> From: semantic-web-request@w3.org [mailto:semantic-web- 
>> request@w3.org]
>> On Behalf Of Russell Duhon
>> Sent: 20 December 2005 23:16
>> To: Frank Manola
>> Cc: semantic-web@w3.org; Joshua Allen
>> Subject: Re: How will the semantic web emerge
>> Its not so much a dichotomy of optional/not optional, but typing-by-
>> properties and typing-by-class.
>> Duck typing is where an object is treated with based on what
>> properties it has, or in python and similar, what methods can be
>> called on it. If I have a function that calls certain methods on the
>> objects passed in, it very well might not matter which objects are
>> passed in, provided they have those methods -- the formal types are
>> not considered directly. This is duck typing -- anything that walks
>> like a duck, quacks like a duck, and looks like a duck might as well
>> be a duck.
>> Those objects (in Python) still have strong types, its just that
>> methods don't have type signatures (at least, not unless you make
>> that happen ;-) ), and the language is dynamically typed. If my
>> method still works whether a string or an integer is passed in, I can
>> pass in either -- but a string is very much not an integer, and there
>> are certain operations that protest very loudly if I try using a
>> string like an integer or an integer like a string!
>> One can also include those checks of object types in one's code, as
>> needed/desired.
>> Now, RDF's not quite in the same situation -- types really are
>> optional, in a sense. But its also going to continue to make sense to
>> create RDF with lots of type-rich information, and create ontologies
>> that can infer types in under-typed RDF.
>> The first is pretty clear because tools for creating RDF and
>> interpreting common sorts of RDF can get a leg up with types. For
>> instance, if I want all RSS items in an RDF store, the type is one of
>> the best ways to get at those. I expect a lot of RDF uses will
>> require certain type information, much like RSS 1.0 effectively does,
>> in order to ensure easy "mining".
>> The second is happening/will happen because it allows for the use of
>> generic reasoners. I won't have to create an application that
>> meticulously examines my RDF data for desired instances, I'll throw a
>> declarative ontology at it, then be able to grab things by type and
>> know they're the sort of thing I want.
>> Because it makes sense for a lot of RDF to be type rich or type
>> enrich-able, I think any view emphasizing type-optionality is missing
>> out on a lot of the potential for RDF. At the same time, any view
>> trying to make all RDF data be strictly typed is flawed as well
>> (particularly as some typing information from OWL Full ontologies and
>> the like will be problematic to determine), and misses out on many of
>> the possibilities for flexible RDF usage that proceed purely based on
>> examining (non-type parts of) the graph.
>> Russell
>> On Dec 20, 2005, at 5:27 PM, Frank Manola wrote:
>>> Russell Duhon wrote:
>>> snip
>>>> Personally, I view RDF as more along  the lines of Python or
>>>> similar important dynamic, strongly typed  languages -- we can
>>>> play fast and loose with it in many ways, using  duck typing, but
>>>> the types are still there to exploit when useful.
>>> This seems like a reasonble position, except that being able to
>>> ignore the types when you want to makes them optional doesn't it?
>>> And playing fast and loose doesn't sound like what I recall of
>>> strong typing!
>>> --Frank

Received on Wednesday, 21 December 2005 16:35:44 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:44:55 UTC