- From: Martynas Jusevičius <martynas@graphity.org>
- Date: Sat, 21 Feb 2015 20:57:51 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-lod <public-lod@w3.org>
Kingsley, I am fully aware of the distinction between RDF as a data model and its serializations. That's why I wrote: "RDF *serializations* often group triples by subject URI." What I tweeted recently was, that despite having concept models and abstractions in our heads, when pipelining data and writing software we are dealing with concrete serializations. Am I not right? So what I mean with "it works" is that our RDF/POST-based user interface is simply a generic function of the RDF graph behind it, in the form of XSLT transforming the RDF/XML serialization. I commented on concurrency in the previous email, but you haven't replied to that. On Sat, Feb 21, 2015 at 8:43 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 2/21/15 1:34 PM, Martynas Jusevičius wrote: >> >> Kingsley, >> >> I don't need a lecture from you each time you disagree. > > > I am not lecturing you. I am trying to make the conversation clearer. Can't > you see that? > >> >> Please explain what you think "Resource" means in "Resource >> Description Framework". >> >> In any case, I think you know well what I mean. >> >> A "grouped" RDF/XML output would be smth like this: >> >> <rdf:Description rdf:about="http://resource"> >> <rdf:type rdf:resource="http://type"/> >> <a:property>value</a:property> >> <b:property>smth</b:property> >> </rdf:Description> > > > You spoke about RDF not RDF/XML (as you know, they are not the same thing). > You said or implied "RDF datasets are usually organized by subject". > > RDF is an abstract Language (system of signs, syntax, and semantics). Thus, > why are you presenting me with an RDF/XML statement notation based response, > when we are debating/discussing the nature of an RDF relation? > > Can't you see that the more we speak about RDF in overloaded-form the more > confusing it remains? > > RDF isn't a mystery. It doesn't have to be some unsolvable riddle. Sadly, > that's its general perception because we talk about it using common terms in > an overloaded manner. > >> >> How would you call this? I call it a "resource description". > > > See my comments above. RDF is a Language. You can create RDF Statements in a > document using a variety of Notations. Thus, when speaking of RDF I am not > thinking about RDF/XML, TURTLE, or any other notation. I am thinking about a > language that systematically leverages signs, syntax, and semantics as a > mechanism for encoding and decoding information [data in some context]. > >> But the >> name does not matter much, the fact is that we use it and it works. > > > Just works in what sense? That's why I asked you questions about how you > catered to integrity and concurrency. > > If you have more than one person editing sentences, paragraphs, or a page in > a book, wouldn't you think handling issues such as the activity frequency, > user count, and content volume are important? That's all I was seeking an > insight from you about, in regards to your work. > > > Kingsley > >> >> >> On Sat, Feb 21, 2015 at 7:01 PM, Kingsley Idehen >> <kidehen@openlinksw.com> wrote: >>> >>> On 2/21/15 9:48 AM, Martynas Jusevičius wrote: >>> >>> On Fri, Feb 20, 2015 at 6:41 PM, Kingsley Idehen >>> <kidehen@openlinksw.com> wrote: >>> >>> On 2/20/15 12:04 PM, Martynas Jusevičius wrote: >>> >>> >>> Not to criticize, but to seek clarity: >>> >>> What does the term "resources" refer to, in your usage context? >>> >>> In a world of Relations (this is what RDF is about, fundamentally) its >>> hard >>> for me to understand what you mean by "grouped by resources". What is the >>> "resource" etc? >>> >>> Well, RDF stands for "Resource Description Framework" after all, so >>> I'll cite its spec: >>> "RDF graphs are sets of subject-predicate-object triples, where the >>> elements may be IRIs, blank nodes, or datatyped literals. They are >>> used to express descriptions of resources." >>> >>> More to the point, RDF serializations often group triples by subject >>> URI. >>> >>> >>> The claim "often group triples by subject" isn't consistent with the >>> nature >>> of an RDF Relation [1]. >>> >>> "A predicate is a sentence-forming relation. Each tuple in the relation >>> is a >>> finite, ordered sequence of objects. The fact that a particular tuple is >>> an >>> element of a predicate is denoted by '(*predicate* arg_1 arg_2 .. >>> arg_n)', >>> where the arg_i are the objects so related. In the case of binary >>> predicates, the fact can be read as `arg_1 is *predicate* arg_2' or `a >>> *predicate* of arg_1 is arg_2'.") " [1] . >>> >>> RDF's specs are consistent with what's described above, and inconsistent >>> with the subject ordering claims you are making. >>> >>> RDF statements (which represent relations) have sources such as documents >>> which are accessible over a network and/or documents managed by some >>> RDBMS >>> e.g., Named Graphs in the case of a SPARQL compliant RDBMS . >>> >>> In RDF you are always working with a set of tuples (s,p,o 3-tuples >>> specifically) grouped by predicate . >>> >>> Also note, I never used the phrase "RDF Graph" in any of the sentences >>> above, and deliberately so, because that overloaded phrase is yet another >>> source of unnecessary confusion. >>> >>> Links: >>> >>> [1] >>> >>> http://54.183.42.206:8080/sigma/Browse.jsp?lang=EnglishLanguage&flang=SUO-KIF&kb=SUMO&term=Predicate >>> >>> Kingsley >>> >>> >>> Within a resource block, properties are sorted >>> alphabetically by their rdfs:labels retrieved from respective >>> vocabularies. >>> >>> How do you handle the integrity of multi-user updates, without killing >>> concurrency, using this method of grouping (which in of itself is unclear >>> due to the use "resources" term) ? >>> >>> How do you minimize the user interaction space i.e., reduce clutter -- >>> especially if you have a lot of relations in scope or the possibility >>> that >>> such becomes the reality over time? >>> >>> I don't think concurrent updates I related to "resources" or specific >>> to our editor. The Linked Data platform (whatever it is) and its HTTP >>> logic has to deal with ETags and 409 Conflict etc. >>> >>> I was wondering if this logic should be part of specifications such as >>> the Graph Store Protocol: >>> https://twitter.com/pumba_lt/status/545206095783145472 >>> But I haven't an answer. Maybe it's an oversight on the W3C side? >>> >>> We scope the description edited either by a) SPARQL query or b) named >>> graph content. >>> >>> Kingsley >>> >>> On Fri, Feb 20, 2015 at 4:59 PM, Michael Brunnbauer <brunni@netestate.de> >>> wrote: >>> >>> 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 >>> >>> >>> >>> -- >>> 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 >>> >>> >>> >>> >>> >>> -- >>> 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 >> >> > > > -- > 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 > >
Received on Saturday, 21 February 2015 19:58:19 UTC