Re: Enhancing object-oriented programming with OWL

Hi,
I don't think you answered the question of how what you propose would be
optimised. How would it deal with reasoning, for instance, bearing in mind
that Pellet and many others have been subject to many years of development
and probably the subject of many Phds too!

You might want to look at this project which Henry Story tipped me off to:-
https://github.com/w3c/banana-rdf

This is from the test suit:-
ObjectExamples.scala

package org.w3.banana

import scalaz.{ Validation, Failure, Success }
import java.util.UUID

class ObjectExamples[Rdf <: RDF]()(implicit diesel: Diesel[Rdf]) {

  import diesel._
  import ops._

  case class Person(name: String, nickname: Option[String] = None)

  object Person {

    val clazz = uri("http://example.com/Person#class")
    implicit val classUris = classUrisFor[Person](clazz)

    val name = property[String](foaf.name)
    val nickname = optional[String](foaf("nickname"))
    val address = property[Address](foaf("address"))

    implicit val container = uri("http://example.com/persons/")
    implicit val binder = pgb[Person](name, nickname)(Person.apply,
Person.unapply)

  }

  sealed trait Address

  object Address {

    val clazz = uri("http://example.com/Address#class")
    implicit val classUris = classUrisFor[Address](clazz)

    // not sure if this could be made more general, nor if we actually want
to do that
    implicit val binder: PointedGraphBinder[Rdf, Address] = new
PointedGraphBinder[Rdf, Address] {
      def fromPointedGraph(pointed: PointedGraph[Rdf]):
Validation[BananaException, Address] =
        Unknown.binder.fromPointedGraph(pointed) orElse
VerifiedAddress.binder.fromPointedGraph(pointed)

      def toPointedGraph(address: Address): PointedGraph[Rdf] = address
match {
        case va: VerifiedAddress =>
VerifiedAddress.binder.toPointedGraph(va)
        case Unknown => Unknown.binder.toPointedGraph(Unknown)
      }
    }

  }

  case object Unknown extends Address {

    val clazz = uri("http://example.com/Unknown#class")
    implicit val classUris = classUrisFor[Unknown.type](clazz,
Address.clazz)

    // there is a question about constants and the classes they live in
    implicit val binder: PointedGraphBinder[Rdf, Unknown.type] =
constant(this, uri("http://example.com/Unknown#thing")) withClasses
classUris

  }

  case class VerifiedAddress(label: String, city: City) extends Address

  object VerifiedAddress {

    val clazz = uri("http://example.com/VerifiedAddress#class")
    implicit val classUris = classUrisFor[VerifiedAddress](clazz,
Address.clazz)

    val label = property[String](foaf("label"))
    val city = property[City](foaf("city"))

    implicit val ci = classUrisFor[VerifiedAddress](clazz)

    implicit val binder = pgb[VerifiedAddress](label,
city)(VerifiedAddress.apply, VerifiedAddress.unapply) withClasses classUris

  }

  case class City(cityName: String, otherNames: Set[String] = Set.empty)

  object City {

    val clazz = uri("http://example.com/City#class")
    implicit val classUris = classUrisFor[City](clazz)

    val cityName = property[String](foaf("cityName"))
    val otherNames = set[String](foaf("otherNames"))

    implicit val binder: PointedGraphBinder[Rdf, City] =
      pgb[City](cityName, otherNames)(City.apply, City.unapply) withClasses
classUris

  }

}

The stated aim of the developers is to follow the RDF spec 'carefully' and
to work with Jena and Sesame, so perhaps not the same as yours?


Adam


On 30 August 2012 17:03, Timothy Armstrong <tim.armstrong@gmx.com> wrote:

>  Hi,
>
> Sorry for taking so long to respond, and thank you for talking to me.
>
> As far as I can tell, it is entirely possible to build Semantic Web
> software on top of object-oriented programming languages, and presumably
> database technologies, instead of starting Semantic Web software from
> scratch.  Object-oriented languages already have a lot of the OWL data
> model implemented.  Well, all they have are classes, properties, and
> rdfs:subClassOf, but they do those very well.  So we want to add the rest
> of OWL to them.
>
> All the property reasoning just works directly for attributes.  Attributes
> can have subattributes, inverse attributes, be transitive, etc., and it all
> makes perfect sense.  We just let people use property reasoning for any of
> their object-oriented attributes.  I tried to show how useful it would be
> in the example program on my web page:
> http://www.semanticoop.org/example.html.  There is a Person Java class
> with attributes for the person's mother, father, parents, children,
> ancestors, descendants, an attribute for all the person's relatives, etc.
> You can imagine how messy the Java program would be without the property
> reasoning.  The reasoning really helps.  Well, maybe there are better ways
> of doing it than with my software, but I think that if we can add OWL to
> OOP, people will really like it.
>
> Well, I really don't know what to do with the software.  Thank you for
> talking to me about it.
>
> Tim Armstrong
>
>
>
> On 08/20/2012 05:21 PM, adasal wrote:
>
> OK, there is something like multiple inheritance in Scala with Scala
> traits and there are a few implementations of mixin frameworks in Java
> which is really IoC using DI. Tapestry was my example, but Spring allows
> similar to enable separation of concerns.
> However I believe that Sesame/AliBaba also allows such hooks.
> When it comes to reasoning there are existing Java reasoners. It seems
> more than a tall order to build your own!
> For instance http://clarkparsia.com/pellet/
> The problem that you will have if you build your own is that you will both
> have to optimise and verify it.
>
>  The mixin pattern is also available in Python, there are some advantages
> against inheritance as run time behaviour can be determined.
>
>  Are you able to explain better the difference and implication of your
> approach to existing approaches?
> It has been said in this thread that code up to the RDF level is the
> better approach, that is the RDF is not fully modelled in the code but
> translated through e.g. SPARQL I suppose.
> How do you understand this?
>
>  Best,
>
>  Adam
>
> On 20 August 2012 16:39, Timothy Armstrong <tim.armstrong@gmx.com> wrote:
>
>>  Hi,
>>
>> Well, if there would be some way to do multiple inheritance in Java, that
>> could be very useful.  I was thinking it would probably be possible to do
>> some of the class reasoning in Java with its limited support for multiple
>> inheritance with interfaces, just we would be partially limited in what we
>> can do with classes in Java.  There shouldn't be a problem with the
>> property reasoning, SPARQL, or rules in Java though (well I have methods to
>> compute all the triplestore indexes).  Semantic Web Services written as
>> Java annotations on methods should work if annotations are extended to
>> support arbitrary datatypes.
>>
>> I could have written the code in a language that has multiple
>> inheritance, but we can do a lot in Java, and Java is just my best
>> language.  It might be straightforward to copy the code to any other
>> object-oriented language.  I just looked at Python decorators this morning,
>> since Python has multiple-inheritance.  It doesn't look straightforward to
>> use them just for metadata on code elements like Java annotations, but
>> maybe it can be done.  If it can, it looks like they would support
>> arbitrary datatypes.  And then maybe we could add all of OWL, SPARQL,
>> rules, and Semantic Web Services to Python without modifying Python...
>> Well, there would need to be something like AspectJ for Python as I'm doing
>> it.
>>
>> Truthfully, I haven't spent much thought about how best to do the class
>> reasoning.  I focused on the property reasoning and indexes and was waiting
>> to talk to people about the class reasoning.  I'll have to look into the
>> technologies you mention.
>>
>> Tim
>>
>>
>>
>> On 08/18/2012 04:55 PM, adasal wrote:
>>
>> We would need to modify a compiler to determine to which classes an
>>> object belongs so we would know what methods can be used with it.  There
>>> could be methods in defined classes.
>>
>>
>>  You must be thinking about a multiple class inheritance hierarchy.
>>
>>  There is this project
>> http://insightfullogic.com/blog/2011/sep/16/multiple-inheritance/
>> but I think there must be other implementations.
>> Further containers for IoC such as Tapestry have a mature mixin
>> implementation for class transformation, or Scala (and Java 8 to be)
>> supports traits.
>>  Wouldn't this cover it instead of messing around with the compiler?
>>
>>  I would have thought the real problem is how to define precedence in
>> the multiple hierarchy. How does OWL deal with contradictory definitions in
>> the hierarchy?
>>
>>  Adam
>>
>> On 18 August 2012 16:10, Timothy Armstrong <tim.armstrong@gmx.com> wrote:
>>
>>>  Hi Adam,
>>>
>>> What I have in mind is fitting my software together with Sesame or Jena
>>> and just having the back-end store sets of objects instead of whole triples
>>> and see how that works.  For benchmarks, I think it won't be very difficult
>>> to get SPARQL running on my software, since I have methods to compute all
>>> the triplestore indexes (permutations of subject-predicate-object) from all
>>> of main memory, but SPARQL isn't running yet.
>>>
>>> I just meant that my understanding was that OWL can express anything
>>> about data OOP can express, and more, but I'm sure Alan is right that there
>>> is more than abstract classes. By "disparity" I meant that even if there
>>> are differences between OOP and OWL of which I'm not aware, I still don't
>>> see a problem with adding OWL to OOP.
>>>
>>> We would need to modify a compiler to determine to which classes an
>>> object belongs so we would know what methods can be used with it.  There
>>> could be methods in defined classes.
>>>
>>> Tim
>>>
>>>
>>>
>>> On 08/18/2012 07:35 AM, adasal wrote:
>>>
>>>
>>>
>>> On 17 August 2012 23:08, Timothy Armstrong <tim.armstrong@gmx.com>wrote:
>>>
>>>> Certainly, object-oriented classes and OWL classes are different, but
>>>> my understanding is that the main difference is just that OWL is strictly
>>>> better.
>>>>
>>>
>>>  What do you mean by 'strictly', 'better' and 'strictly better'?
>>>
>>>
>>>>   I'm not aware of anything OOP can do that OWL cannot do, but OWL can
>>>> do a lot more.
>>>>
>>>
>>>  What do you mean by 'do'? Do you mean it is more expressive such that
>>> it is possible to define in OWL what cannot be defined in OOP? Isn't that
>>> axiomatic in that they are different languages with different semantics?
>>> What you are really saying is that you want to extend the syntax of OOP
>>> in a form you think is convenient to use such that it will be able to
>>> express OWL semantics.
>>>
>>>  Well, abstract classes, but that's all I can think of.
>>>>
>>> So is this relevant?
>>>
>>>  Or if there is still going to be a disparity,
>>>>
>>> What does this mean?
>>>
>>>
>>>> we should still just be able to add all the OWL class constructs and
>>>> everything else about OWL and let people use them in OOP.
>>>>
>>> You mean with your annotations - but the issue really is whether this is
>>> more convenient than existing approaches.
>>>
>>>
>>>> We'd need to get into a compiler to do some of it, but I think it would
>>>> be worth it.
>>>>
>>> Why would it be necessary to get into the compiler, what are you talking
>>> about?
>>> Do you mean to pick up annotations - that is not necessary as new
>>> annotations can be defined as things stand - or to optimise such as in the
>>> way you mention where reasoning is selective. I can't see that this needs
>>> access to the compiler so much as an understanding of the logic of whether
>>> and when selective reasoning is a proper optimisation.
>>>
>>>  You would have to show that your approach is better than the existing
>>> approaches to optimisation that sit on top of triple and quad stores.
>>> Can you do this?
>>>
>>>  Adam
>>>
>>>
>>>
>>
>>
>
>