Re: "Microsoft Access" for RDF?

On 2/20/15 10:23 AM, 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.

That's because dog-fooding hasn't yet become second nature, across the 
aforementioned communities. Don't give up, just keep pushing the case 
via real  examples etc..

>
> However when a concrete example is shown, which solves the issue
> discussed or at least comes close to that, it receives no response.

Yes, that is the general case, but don't give up. Keep pushing, things 
will change, they have too!

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

Please keep up your good work and overall effort in general. Don't get 
frustrated (I know that's easier said than done).

RDF Editors are vital, in regards to bootstrapping a Read-Write Linked 
Open Data ecosystem. The more the merrier, as long as the solutions in 
question are based on open standards (RDF, SPARQL, LDP, HTTP, URIs, 
WebDAV etc..).


Kingsley
>
> 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.
>>
>>
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this