- From: Michael Brunnbauer <brunni@netestate.de>
- Date: Fri, 20 Feb 2015 16:59:38 +0100
- To: Martynas Jusevi??ius <martynas@graphity.org>
- Cc: "public-lod@w3.org" <public-lod@w3.org>
- Message-ID: <20150220155938.GA8828@netestate.de>
Hello Martynas, sorry! You mean this one? http://linkeddatahub.com/ldh?mode=http%3A%2F%2Fgraphity.org%2Fgc%23EditMode Nice! Looks like a template but you still may have the triple object ordering problem. Do you? If yes, how did you address it? Regards, Michael Brunnbauer On Fri, Feb 20, 2015 at 04:23:14PM +0100, Martynas Jusevi??ius wrote: > I find it funny that people on this list and semweb lists in general > like discussing abstractions, ideas, desires, prejudices etc. > > However when a concrete example is shown, which solves the issue > discussed or at least comes close to that, it receives no response. > > So please continue discussing the ideal RDF environment and its > potential problems while we continue improving our editor for users > who manage RDF already now. > > Have a nice weekend everyone! > > On Fri, Feb 20, 2015 at 4:09 PM, Paul Houle <ontology2@gmail.com> wrote: > > So some thoughts here. > > > > OWL, so far as inference is concerned, is a failure and it is time to move > > on. It is like RDF/XML. > > > > As a way of documenting types and properties it is tolerable. If I write > > down something in production rules I can generally explain to an "average > > joe" what they mean. If I try to use OWL it is easy for a few things, hard > > for a few things, then there are a few things Kendall Clark can do, and > > then there is a lot you just can't do. > > > > On paper OWL has good scaling properties but in practice production rules > > win because you can infer the things you care about and not have to generate > > the large number of trivial or otherwise uninteresting conclusions you get > > from OWL. > > > > As a data integration language OWL points in an interesting direction but it > > is insufficient in a number of ways. For instance, it can't convert data > > types (canonicalize <mailto:joe@example.com> and "joe@example.com"), deal > > with trash dates (have you ever seen an enterprise system that didn't have > > trash dates?) or convert units. It also can't reject facts that don't > > matter and so far as both time&space and accuracy you do much easier if you > > can cook things down to the smallest correct database. > > > > ---- > > > > The other one is that as Kingsley points out, the ordered collections do > > need some real work to square the circle between the abstract graph > > representation and things that are actually practical. > > > > I am building an app right now where I call an API and get back chunks of > > JSON which I cache, and the primary scenario is that I look them up by > > primary key and get back something with a 1:1 correspondence to what I got. > > Being able to do other kind of queries and such is sugar on top, but being > > able to reconstruct an original record, ordered collections and all, is an > > absolute requirement. > > > > So far my infovore framework based on Hadoop has avoided collections, > > containers and all that because these are not used in DBpedia and Freebase, > > at least not in the A-Box. The simple representation that each triple is a > > record does not work so well in this case because if I just turn blank nodes > > into UUIDs and spray them across the cluster, the act of reconstituting a > > container would require an unbounded number of passes, which is no fun at > > all with Hadoop. (At first I though the # of passes was the same as the > > length of the largest collection but now that I think about it I think I can > > do better than that) I don't feel so bad about most recursive structures > > because I don't think they will get that deep but I think LISP-Lists are > > evil at least when it comes to external memory and modern memory > > hierarchies. > > > > -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Straße 11a ++ 81379 München ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail brunni@netestate.de ++ http://www.netestate.de/ ++ ++ Sitz: München, HRB Nr.142452 (Handelsregister B München) ++ USt-IdNr. DE221033342 ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Received on Friday, 20 February 2015 16:00:08 UTC