To put this in concrete terms, suppose I find an RDF document that contains,
among hundreds of other triples:
X R1 A
X R2 B
X R3 C
A R4 XXX
C R5 YYY (01)
and I am really interested in X R2 B. It may be very important that I
understand X R1 A, because A R4 XXX, which affects the whole meaning of X R2 B.
At the same time X R3 C and anything further in that vein is completely
irrelevant. Determining the elements of the document on which we want to
'focus attention' is not an easy task. And the task for both human and machine
intelligence may be made easier if the author put the 3 relevant triples in the
same section or subgraph, and more difficult if not. (02)
-Ed (03)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Barkmeyer, Edward J
> Sent: Tuesday, September 17, 2013 12:04 PM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] ONTOLOG community event planning and
> scheduling session - Thu 2013.09.12 & Thu 2013.09.19
>
> Paul,
>
> I may have misunderstood Gary's point as well, but what I thought he was
> saying is that a document is a whole, and the interpretation of one part may
> depend on another that is only structurally connected in the formal form, but
> is more tightly connected in its semantic intent. For example, a document
> may begin by saying: For the analysis in this paper, we made the following
> assumptions: A, B, C. There follows a set of "facts" and analytical results,
>and
> for many X among those assertions, the intended meaning is: If A and B and
> C then X. The structure of the document may be Clause 1 Assumptions,
> Clause 2 data sources and data, Clause 3 analytical results. The structure of
> the document is three serialized 'named graphs', but what is the semantic
> intent of the serialization and how is that captured? If I am accessing that
> resource for presentation to a human, I can use RDF effectively in identifying
> at least a probable match on search criteria, but I am depending on the
> human to read enough of the whole document to understand the meaning
> of its parts. Trying to 'understand the intended interpretation of a sentence
> in clause 3' with AI methods is a very different problem, and using LOD
> techniques to excerpt stuff from Clause 3 without that understanding is
> downright risky.
>
> The same authors may also reorganize the same Clause 2 data for use in a
> related study. Can you recognize that the data is the same if it has been
> reorganized?
>
> The underlying problem is that we cannot communicate without organizing
> the presentation of the information we intend to communicate, and we
> know from many studies that reorganizing that same information can lead to
> mis-communication for certain audiences. That is why the unit of import for
> ontologies and other models is an entire ontology or model. Languages/tools
> that allow selective import still semantically import the whole source model,
> they just limit the visibility of symbols taken from that model.
>
> That is, a document/resource, in RDF or any other language, is a unitary
> corpus that is organized to convey information. The corpus may have a lot of
> different information "particles" in it, many of which really are separable
> from one another, but many of which are also integrally related. If you
> excerpt from it, you have to understand its organization in order to take from
> it all that is needed to convey the intent of the excerpt.
>
> -Ed
>
> (Now, Gary will tell me that this is not quite, or not at all, what he
>meant...)
>
> "I will always treasure the moment a senior client at a workshop walked up to
> a flip chart picture that someone had just drawn, with lines and boxes all
>over
> the place, and announced to his underlings:
> 'I like this picture! What this picture tells me is ....' and then proceeded
>to
> expound the precise opposite of the point the consultant was trying to
> make."
> -- Sandy Tyndale-Biscoe
>
> --
> Edward J. Barkmeyer Email: edbark@xxxxxxxx
> National Institute of Standards & Technology Systems Integration Division
> 100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
>
> "The opinions expressed above do not reflect consensus of NIST, and have
> not been reviewed by any Government authority."
>
>
>
>
>
> > -----Original Message-----
> > From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> > bounces@xxxxxxxxxxxxxxxx] On Behalf Of Paul Tyson
> > Sent: Monday, September 16, 2013 9:43 PM
> > To: [ontolog-forum]
> > Subject: Re: [ontolog-forum] ONTOLOG community event planning and
> > scheduling session - Thu 2013.09.12 & Thu 2013.09.19
> >
> > On Sun, 2013-09-15 at 18:02 -0400, Gary Berg-Cross wrote:
> > > P
> > > aul
> > >
> > >
> > > >
> > > Documents, being packages of differences, can be decomposed into
> > > particles of significance related in particular ways.
> > > >
> > > RDF is a good way to represent, record, and exchange particles of
> > > significance that are related in particular ways.
> > >
> > > There are many potential problems in the this formulation of package
> > > decomposition and its representation in particular ways.
> >
> > I would say "opportunities" instead of "problems". Did you mean "gaps"
> > or "insufficiencies"--and if so, any in particular?
> >
> > >
> > >
> > > One must understand how a "whole" document is composed with
> relations
> > > from its various parts and how a who;e may emerge from related parts.
> > If you mean by that, "document design", I agree. There's no technology to
> > replace thinking. As for the mechanics of composing and delivering
> > documents, the XML technology stack provides almost everything needed.
> >
> > Regards,
> > --Paul
> > >
> > >
> > >
> > >
> > >
> > > Gary Berg-Cross, Ph.D.
> > > gbergcross@xxxxxxxxx
> > > http://ontolog.cim3.net/cgi-bin/wiki.pl?GaryBergCross
> > > NSF INTEROP Project
> > >
> >
> http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0955816
> > > SOCoP Executive Secretary
> > > Knowledge Strategies
> > > Potomac, MD
> > > 240-426-0770
> > >
> > >
> > > On Sun, Sep 15, 2013 at 9:11 AM, Paul Tyson <phtyson@xxxxxxxxxxxxx>
> > > wrote:
> > > I like Kingsley's "data-de-silo-fication" theme. (In fact, I'm
> > > soon to
> > > give an internal tech talk called "Down With Silos! How linked
> > > data is
> > > beautifying the information landscape").
> > >
> > > I want to contribute a different narrative, orthogonal to the
> > > engineering discussion in this thread, but leading I think to
> > > the same
> > > place Kingsley is heading. For brevity I'll keep it to bullet
> > > points.
> > >
> > > 1. Enterprises depend for their success on people in the
> > > enterprise
> > > doing the right thing at the right time.
> > > 2. People only know what is the right thing and how to do it
> > > by getting
> > > good information in the form most useful to them at the time
> > > they need
> > > it.
> > > 3. They get the information they need primarily from
> > > "documents", taken
> > > in the very general sense as some bounded, structured,
> > > purposeful
> > > package of distinctions (glyphs, lines, colors, shapes,
> > > texture, sound,
> > > image, etc.).
> > > 4. Documents, being packages of differences, can be decomposed
> > > into
> > > particles of significance related in particular ways.
> > > 5. RDF is a good way to represent, record, and exchange
> > > particles of
> > > significance that are related in particular ways. Along with
> > > XML, HTML,
> > > HTTP, and related W3C standards, we have a complete suite of
> > > tools for
> > > delivering documents containing the information needed to the
> > > people who
> > > need it to act for the success of the enterprise.
> > >
> > > There should be no dispute about RDBMS as an efficient storage
> > > and
> > > retrieval machinery for relational data. I appreciate hearing
> > > about the
> > > engineering and theoretical issues about such systems.
> > > However, those
> > > issues are related to the problems of getting information to
> > > people at
> > > the point of need only to the extent that system designers
> > > choose to
> > > couple data persistence components to data delivery
> > > mechanisms. One of
> > > the hallmarks of "legacy" systems is the unfortunate choice to
> > > closely
> > > couple these components.
> > >
> > > I expect the discussion in this forum to focus on how to
> > > deliver
> > > information to a human in the way that best meets his or her
> > > constantly
> > > changing and not entirely predictable needs. Whether the data
> > > is
> > > persisted on disk or papyrus, in Elbonian, SQL, NoSQL, or
> > > Linear B, may
> > > be of great concern to the designers and engineers tasked with
> > > supporting the information needs of an enterprise. But it
> > > should be
> > > immaterial to discussions about what happens directly on each
> > > side of
> > > the computer screen: that is, how documents are composed for
> > > display,
> > > and how they are interpreted by the human on the other side of
> > > the
> > > screen.
> > >
> > > Those of us who focus on the 2-sides-of-the-screen problem
> > > domain have
> > > found the W3C basic and semantic web technology stacks of
> > > inestimable
> > > value.
> > >
> > > Regards,
> > > --Paul
> > >
> > > On Fri, 2013-09-13 at 10:07 -0400, Kingsley Idehen wrote:
> > > > On 9/13/13 9:33 AM, Michael Brunnbauer wrote:
> > > >
> > > > > Hello Kingsley,
> > > > >
> > > > > On Fri, Sep 13, 2013 at 08:37:01AM -0400, Kingsley Idehen
> > > wrote:
> > > > > > > I agree wholeheartedly. RDF and SPARQL make data
> > > integration easier
> > > > > > > (without
> > > > > > > solving the fundamental issues of course).
> > > > > > What is the fundamental issue, as you see it?
> > > > >
> > >
> >
> http://en.wikipedia.org/wiki/Heterogeneous_database_system#Problems_
> > of_heterogeneous_database_integration
> > > > ## In Turtle, for sake of clarity re, my world-view ##
> > > >
> > > >
> > >
> >
> <http://en.wikipedia.org/wiki/Heterogeneous_database_system#Problems
> > _of_heterogeneous_database_integration>
> > > > <#myLabel> "Data-de-silo-fication" ;
> > > > <#sameAs> <#HeterogeneousDataFederation>,
> > > <#DataVirtualization>,
> > > > <#DataSpaces>, <#MasterDataManagement> ;
> > > > <#comment> """This problem covers data disparity issues that
> > > include:
> > > > shape, location, and relation semantics (or lack
> > > thereof)""" .
> > > >
> > > > ## Turtle End ##
> > > >
> > > > So I assume we are in agreement re., the problem?
> > > >
> > > > >
> > > > >
> > > http://lists.w3.org/Archives/Public/public-lod/2013Jun/0458.html
> > > > >
> > > > > > I see the fundamental issue (or pain point) being
> > > data-de-silo-fication.
> > > > > RDF is nice for Extract Transform Load. The problems start
> > > if you want to
> > > > > change data.
> > > >
> > > > Change sensitivity is handled via the use of Linked Data
> > > Views over
> > > > disparate data sources. This is what R2RML facilitates
> > > albeit rarely
> > > > mentioned, sadly.
> > > >
> > > > Views can be transient, materialized, or a configurable mix
> > > of both.
> > > > That's certainly the case re. Virtuoso i.e., make a change
> > > in its SQL
> > > > DBMS (or a remote ODBC or JDBC accessible DBMS) and they are
> > > reflected
> > > > in all your SPARQL queries and Linked Data URI lookups. The
> > > same even
> > > > applies to RESTful or SOA services that are attached to
> > > Virtuoso (we
> > > > cover 100+ protocols and formats).
> > > >
> > > > We have Replication (Snapshot and Transactional) and HTTP
> > > (including
> > > > cache invalidation) baked into Virtuoso.
> > > >
> > > > >
> > > > > > > But they are a bad option for data
> > > > > > > storage because maintaining consistency is so
> > > difficult (think about
> > > > > > > deleting
> > > > > > > a row or transactions).
> > > > > > I don't know what that really means.
> > > > > Suppose you have an App with user registration. If you
> > > store the user data
> > > > > in a triple store, deleting a user with SPARQL becomes
> > > difficult.
> > > >
> > > > That doesn't apply to every triplestore. That doesn't apply
> > > to
> > > > Virtuoso. We even have large customer running OLTP like
> > > workflows with
> > > > something like 40 million named graphs. BTW -- as part of
> > > the
> > > > workflow, Virtuoso has to factor in deltas such that it
> > > doesn't
> > > > perform wholesale named graph deletions etc.
> > > >
> > > > > Removing
> > > > > a single triple is not enough. Storing the user in a named
> > > graph may help but
> > > > > probably creates other problems and definitely makes
> > > querying a lot more
> > > > > complicated.
> > > > >
> > > > > What about SPARQL transactions ? Starting a transaction,
> > > reading and updating,
> > > > > commiting the transaction.
> > > >
> > > > We are a full blown ACID DBMS. See our benchmark reports.
> > > These simply
> > > > aren't new issues since we have a hybrid DBMS.
> > > >
> > > > > Is there a triple store that supports this with
> > > > > all the fidelity of modern RDB systems ?
> > > >
> > > > Yes. It's called Virtuoso !
> > > >
> > > > >
> > > > > > I say that because we simply don't have that problem in
> > > our hybrid DBMS.
> > > > > I don't know what that really means. Can I modify data
> > > with SPARQL *and* SQL
> > > > > in your DBMS ? If yes, how does that work ?
> > > >
> > > > Of course you can. We support SPARQL 1.1 Update. We are
> > > SQL-99
> > > > compliant. We do ACID. We have serious customers doing OLTP
> > > like stuff
> > > > using RDF or SQL aspects of Virtuoso. [1][2][3][4]
> > > >
> > > > Links:
> > > >
> > > > 1. http://bit.ly/ZOCmaD -- shows we even have the
> > > performance
> > > > difference between SPARQL and SQL down to insignificant
> > > levels via
> > > > Star Schema Benchmark Report
> > > > 2. http://bit.ly/10pvAbF -- blog post about this effort
> > > > 3. http://bit.ly/Yf5etP -- Berlin SPARQL Benchmark Report
> > > (note: this
> > > > particular benchmark is SQL relational DBMS oriented)
> > > > 4. http://bit.ly/14ULX2F -- 150 Billion triples scale report
> > > > 5. http://bit.ly/RtdGjA -- CoRelational DBMS Concepts post
> > > that
> > > > includes live links to R2RML Views built atop SQL data
> > > > 6. http://bit.ly/13fnIbr -- example of R2RML views atop an
> > > Oracle DBMS
> > > > hooked into Virtuoso via ODBC .
> > > >
> > > >
> > > > Kingsley
> > > > >
> > > > > Regards,
> > > > >
> > > > > Michael Brunnbauer
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> >
> __________________________________________________________
> > _______
> > > > > Message Archives:
> > > http://ontolog.cim3.net/forum/ontolog-forum/
> > > > > Config Subscr:
> > > http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > > > > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > > > > Shared Files: http://ontolog.cim3.net/file/
> > > > > Community Wiki: http://ontolog.cim3.net/wiki/
> > > > > To join:
> > > http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Regards,
> > > >
> > > > Kingsley Idehen
> > > > Founder & CEO
> > > > OpenLink Software
> > > > Company Web: http://www.openlinksw.com
> > > > Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> > > > Twitter/Identi.ca handle: @kidehen
> > > > Google+ Profile:
> > > https://plus.google.com/112399767740508618350/about
> > > > LinkedIn Profile: http://www.linkedin.com/in/kidehen
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> __________________________________________________________
> > _______
> > > > Message Archives:
> > > http://ontolog.cim3.net/forum/ontolog-forum/
> > > > Config Subscr:
> > > http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > > > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > > > Shared Files: http://ontolog.cim3.net/file/
> > > > Community Wiki: http://ontolog.cim3.net/wiki/
> > > > To join:
> > > http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> > > >
> > >
> > >
> > >
> >
> __________________________________________________________
> > _______
> > > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> > > Config Subscr:
> > > http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > > Shared Files: http://ontolog.cim3.net/file/
> > > Community Wiki: http://ontolog.cim3.net/wiki/
> > > To join:
> > > http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> > >
> > >
> > >
> > >
> > >
> >
> __________________________________________________________
> > _______
> > > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> > > Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > > Shared Files: http://ontolog.cim3.net/file/
> > > Community Wiki: http://ontolog.cim3.net/wiki/
> > > To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> > >
> >
> >
> >
> __________________________________________________________
> > _______
> > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> > Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > Shared Files: http://ontolog.cim3.net/file/
> > Community Wiki: http://ontolog.cim3.net/wiki/
> > To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> >
>
> __________________________________________________________
> _______
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> (04)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (05)
|