Actually, many folks have suggested this over the last few years. (01)
I would suggest that the meta-referencing of
triples as subjects of subsequent triples is
exactly what we need n-aries or "tuples" to
accomplish more easily. Computationally, our
machines can handle these kinds of layered
relationships. It's our notations and our wetware
(these brains we carry around in the between our
ears and behind our eyes) that have difficulty
with the processes. Some (mine) more than others. (02)
I have toyed with a sequential 3D representation
of quads as ways to depict the next gen databases
we need and I have at least one colleague working
on a reliable representation of and set of
computations for hypercube analytics, but I
confess he loses me very quickly when explaining
it. However, I'm pretty sure I can represent it
if he can get reliable results. A testable alpha
SDK is coming soon, and if I can't break it, I
will try to convince him to share it more widely
(after making sure all the IPR issues are
settled). Regardless, there's no doubt that this
is the direction we'll go, IMHO. (03)
Right now I think it is more important to get our
ontological houses in order so that we can make
use of this computational power. By that I mean
that we need to have the highest quality
ontologies possible for higher order logic
systems to work with. (04)
However, we are , at least, making a decent start on it all. (05)
Cheers,
Rex (06)
At 4:47 PM +0700 9/7/07, paola.dimaio@xxxxxxxxx wrote:
>quadruples, next gen semantics perhaps?
>
>I got the idea of quadruples from reding the draft of chap X of Dr
>Azamat's forthcoming book.
>It seemed an interesting idea at the time, and a little bit mor than a fantasy
>(I admittedly have limited knowledge)
>now I see it discussed in the context below, might be of interest to
>some on this list too
>
>Azamat, I think thats the strongest contribution of yours
>have you seen it discussed anywhere else?
>
>pdm
>
>----- Original Message -----
>From: Stephen D. Williams
>To: Michael Schneider
>Cc: Bijan Parsia ; Richard Cyganiak ; K-fe bom ; semantic-web@xxxxxx ;
>Jenn Sleeman ; linux@xxxxxxxxxxxxxxxxx ; Jim Hoover ;
>dminorfugue@xxxxxxxxx ; Bruce Israel ; Behling, Josef ; Chuck Bell ;
>Michael Gray ; Ryszard S. Michalski
>Sent: Friday, September 07, 2007 1:59 AM
>Subject: Polyphasic Knowledge Representation, Named graphs, quads,
>quints, K-arity. was: Re: statements about a graph (Named Graphs,
>reification)
>
>
>I agree with most or all of your reasoning below.
>Early this year, I was talking to Tim BL in Boston just before the
>Semantic Web interest group meeting and my main question was: Why
>Triples and not Quads? His immediate response is that they are quads,
>just not explicit in the typical syntaxes, except N3 where you can
>(re)state a triple as the subject of another triple, thereby
>meta-referencing it. (This is still ambiguous, as noted in: [1].)
>
>In my mind, this type of quad, and the idea of named graphs, and of
>RDF document's URL/URI as the ID of the resulting graph, all are the
>same or overlapping concepts with a little semantic sugar. Triples
>are always quads where the statement "handle" is implicit. More
>clearly, there are two implicit things about a triple: the identity of
>the triple (which, traditionally I think, is most clearly represented
>by the complete value of that triple) and the context of that triple.
>In that sense, statements are actually _quints_. There are many
>reasons to make statements, or otherwise draw conclusions, based on
>the identity and context of a triple, yet there is no easy way to do
>this in many cases and fewer ways to interchange this effectively.
>
>This has to be fixed, sooner or later. I understand that it has taken
>time to absorb and react to the first steps of the knowledge
>representation capabilities and implications of the Semantic Web / RDF
>/ OWL work. We now are increasingly bumping into the limitations of
>simple triples. Reification, meta-chains of statements, and (worst of
>all) one-for-one mapping statements can all technically solve parts of
>the "advanced" problems encountered in the real world, but they are
>all very clumsy in practice and make search and traversal needlessly
>complex.
>
>In some of the work I do, I need to solve problems that RDF/OWL/etc.
>are seemingly perfect for, except that I need the following:
>
>Statements versioned by time (all versions in the same knowledge base
>(KB), and the ability to reason over them by time) with both
>happened-at and known-by timestamps.
>Provenance for statements and contexts, including various measures of
>likelihood, trust, probability.
>Security levels, ownership, ACLs, etc.
>Dependency - derived from chains for tracking, explaining, and
>cleaning up after (i.e. retraction / knowledge maintenance) automated
>reasoning engines.
>
>Alternate versions of statements / properties from different
>provenance or even different likelihoods or theories from the same
>source.
>Views of subsets of large KBs of this data, including flat temporal,
>series temporal, security policy, viewpoint/provenance
>filtering/merging, etc.
>The ability to generate, share, and efficiently make use of a "delta"
>or stack of "deltas" between a parent document / KB and updates.
>Ideally, this or similar mechanism would allow rapid access to the
>result of combining many clumps that resulted in a particular view.
>
>The resulting views are slices through the KB which can be thought of
>as planar in a "horizontal", point in time, or "vertical", over a
>period of time, direction through clumps of statements and their
>versions. The slices themselves can be simple RDF or something of
>higher K-arity. K-arity refers to the degree and type of data beyond
>K3=RDF triples.
>
>Minimally, explicit quads would be a huge improvement, while implicit
>quads would still exist in certain contexts. A (locally or globally)
>unique statement ID allows concise triples rather than reification and
>a handle to indicate any provenance, context/group/URI membership,
>etc. Versioning with quads is doable as a new quad could have a
>statement pointing to the old or alternate versions. This is somewhat
>unsatisfying because it would require analysis and maintenance to make
>changes that should be simple "insert this triple-plus-timestamp"
>which would, in most cases, logically replace the old version. One
>option is to reuse the same statement ID with a different timestamp
>(or provenance or other K-arity attribute) and different content. A
>flat view sees only a single version now or at a particular point in
>time.
>
>A full-blown representation might have statements that include, in
>addition to S-P-O: statement identity, context, both timestamps,
>provenance id/context, security context, and dependency context: K10.
> Many of these might point to a node that might link to many values
>and in turn be shared by many statements. Some part of the time, that
>may be desirable. In some applications however, these sometimes
>fundamental meta-properties of a statement are used pervasively and
>cumbersome if they don't have special status. Queries and results
>could be greatly simplified if filtering were done in layered and
>mostly automatic ways and results were simplified into key statements
>with most metainformation being more subtly managed and represented.
>This can all be done, technically, with triples and reification. In
>practice however, both in-memory during queries, response, iteration,
>and other operations and for interchange, it seems much better to have
>key pervasive metainformation have standard ontology / slots. This
>could possibly to be managed as a combination of tuples and context
>graphs (which commonize the shared metainformation to reduce
>per-statement K-arity). I have some SPARQL extensions designed that
>work well with time for instance, greatly simplifying certain
>knowledge filtering constraints.
>
>I call this set of requirements the "Polyphasic Knowledge
>Representation Problem" and my partial solutions "Polyphasic Knowledge
>Representation" (PKR). (I'm open to a better name if you can
>summarize better. "Polyphasic" seems like a good physics analogy
>where different versions and provenances of overlapping information
>are available in overlapping "phases" of knowledge. Some people think
>it's a little too Trek-kitsch.) Many of these may seem special-case
>or "advanced" to many, but I feel this is where things are going. It
>is not hard to find direct use in a lot of this availability of data
>and metadata for various businesses including retail analysis,
>credit/banking, research, sales tracking and analysis, etc.
>
>Additionally, I have been active in the area of efficient (both size
>and processing) XML interchange and representation. This has been the
>topic of the Binary XML (now completed) and Efficient XML Interchange
>[2] (now in progress) working groups. As I am now defining an
>efficient RDF interchange and representation, the problems of what are
>actually needed for an "advanced" and efficient solution provide key
>requirements. The K-arity PKR effective structure of knowledge, where
>K={3-10}, seems to cover it. Is there a good, strong argument against
>this kind of representation, given that conversion to or through K3
>should be possible?
>
>Additionally, part of my thinking and work, but not the XBC or EXI
>working group consensus, is the idea of a type of format that is
>directly and randomly accessible _and_ modifiable in place in a
>reasonably efficient way, in addition to support for low-level deltas
>and stable virtual pointers. Knowledge representation for high
>performance applications is the application that lead to those
>concepts in the first place.
>
>Comments and interest are welcome. I could use suggestions on
>solution ideas and best venues to publish papers.
>
>[1] http://www.w3.org/TR/rdf-primer/#reification
>[2] http://www.w3.org/TR/2007/WD-exi-20070716/
>
>sdw
>
>Michael Schneider wrote:
>[sorry, this has again become a very long mail]
>
>Hi, Richard and Bijan!
>
>
>-----Original Message-----
>From: semantic-web-request@xxxxxx
>[mailto:semantic-web-request@xxxxxx] On Behalf Of Bijan Parsia
>Sent: Tuesday, September 04, 2007 6:51 PM
>To: Richard Cyganiak
>Cc: Michael Schneider; K-fe bom; semantic-web@xxxxxx
>Subject: Re: statements about a graph (Named Graphs, reification)
>
>
>On 4 Sep 2007, at 17:30, Richard Cyganiak wrote:
>
>
>Michael,
>
>On 4 Sep 2007, at 15:29, Michael Schneider wrote:
>
>Ok, then let's discuss more practical issues (leaving this
>
>subtle RDF
>
>semantics stuff to the academic world). Until now, we had the only
>usecase
>that someone wanted to annotate a complete RDF document,
>
>Sorry to be jumping in, but do you mean "in this thread"?
>
>
>Yes. I tried to be at least a little on-topic. ;-)
>
>
>Because other use cases are prevalent.
>
>
>which already exist
>somewhere having an URI. This is certainly the easiest case to
>handle in
>practice.
>
>Yes. I think it's also by far the most common case.
>
>I think almost certainly not. Consider EARL:
> http://www.w3.org/TR/EARL10-Schema/
>
>Or annotation axioms in OWL 1.1.
>
>Or Swoop Change Sets (which do chunk out, so they are a little
>different).
>
>
>But there will probably often be the more demanding situation,
>where I want to make assertions about some ad hoc set of RDF
>triples, which
>is not yet published as a special RDF document anywhere.
>
>To be honest, I'm not sure that this case occurs *that* much in
>practice.
>
>Quite often (or will). I want to record when an axiom in my owl
>ontology has been last modified. Do I have extract that axiom and
>publish it in a separate document?
>
>
>I have been pondering about some specific szenario for quite a while now,
>which I did not yet see being discussed elsewhere. And I would like to know
>from you what you are thinking about it. I will try to present this scenario
>in the form of a little story, because this will make things easier to
>understand.
>
>Assume there is Alice, who owns a homepage, which is enriched with some
>additional RDF. One of the statements within her homepage is
>
> me:alice foaf:knows he:bob .
>
>by which Alice tries to tell the world that she knows some other person Bob.
>
>Now there is Charly, who is an old friend of both Alice and Bob. He knows,
>that Alice knows Bob since 1998. Charly also owns an RDF'ed homepage, and so
>he likes to make this knowledge explicit by stating something like
>
> "Alice knows Bob" dc:date 1998 .
>
>Charly does not have access to Alice's homepage, so she cannot put this
>statement just into Alice's triple store, or even adjust Alice's
>foaf:knows-triple into some n-tuple. But even if she could, she would not
>like to do this: It's actually her, who asserts this statement, so this
>information should really go into her own triple store. But what she wants
>to ensure in any case is that this statement is "visible" on the semantic
>web. This means that if anyone (or any semantic web crawler) should stumble
>over this statement, he/it should, with pretty high confidence, be able to
>understand that this is really a statement which annotates Alice's
>foaf:knows statement - rather than just being some arbitrary RDF triple.
>
>Last, there is Dave. Dave has recently found Alice's homepage with her
>"foaf:knows" statement within. Dave does not know Alice personally, but he
>is very interested in social relationships between arbitrary people. And
>more, he is interested in what others have to say about such social
>relationships. :) So he wonders if there are any additional statements about
>Alice's foaf:knows statement anywhere on the Semantic Web. Dave has already
>installed a copy of the Semantic Web Client Library [1], so he has at least
>a good chance to have access to some larger portions of the SemanticWeb
>(let's suppose for a moment that we are already a few years in the future
>from now, where there is already satisfying linking between existing data).
>Now, what SPARQL query should he execute? He want's to find as many
>assertions about the Alice's foaf:knows statement, as possible, but he also
>want's to avoid too many false positives, of course.
>
>So, this example demonstrates the scenario. There are on the one hand
>parties (the Alices) which create informations on the SemWeb, encoded in
>triple form. There are other parties (the Charlies) wanting to create
>annotations for these triples in separated stores. These parties are
>interested in having their stored annotations encoded in a searchable way.
>And there are again other parties (the Daves) which like to search for such
>triple annotations.
>
>Now, the above example is a little oversimplified, I admit. But it is not
>hard for me to imagine professional mashup services ("Charly 2.0" :)), which
>crawl the whole Semantic Web for triple data of a specific kind (e.g. social
>relationships), and then enrich this found data by additional annotations.
>This will provide quite new views on the original data. For these mashup
>services it will be of utmost importance that their triple annotations will
>be effectively searchable. And then, there will also be general SemanticWeb
>search services (the professional Daves). The value of these search services
>will enhance largly for their users, if these services also take the triple
>annotations of the diverse mashup services into account.
>
>So, there are two questions here, which turn out to be closely related:
>
> * How should triple annotations be encoded on the public Semenatic Web, so
>that they can easily be detected, and identified to really be triple
>annotations?
>
> * How should queries for triple annotations look like in the Semantic Web?
>
>First, it is clear that if Charly uses some special custom method to encode
>her triple annotations, there will be no realistic perspective that her data
>will be found. "Custom reification" methods can be completely resonable for
>being used within specific applications, or for closed user groups. But for
>a searcher like Dave, who wants to broadly query the whole SemanticWeb for
>data created by possibly lots of different, unknown, and unrelated parties,
>this is certainly not an option. But even, if Dave really is going to
>include specialized encoding schemes into his query, then this will only be
>the published schemes of very important parties. So no hope then for Charly
>(and many other normal users or "small players" in the Semantic Web) to get
>their data being found.
>
>So what will happen in such a situation? If no standard encoding scheme
>already exists, there will probably emerge a few encoding schemes, rapidly
>introduced by some first-to-marked organisations (simply because these orgs
>need such a scheme AFAP), and everyone else will then use these few schemes.
>And after some years of usage, the W3C would step in making a standard based
>on those encoding schemes which have survived until then.
>
>But in the case of RDF, I think that people will rather adopt RDF
>reification, for several reasons:
>
> * It's already there, ready for use, and it's part of the official RDF
>standard.
>
> * It is just more triple data, so it can simply be put into the existing
>triple stores. And every RDF aware software out there will be able to handle
>this kind of data out of the box.
>
> * It seems reasonably easy to understand and use for non-expert people (I
>have experienced this, when I tried to explain RDF reification to a complete
>RDF novice).
>
> * There is existing tool support (like in Topbraid Composer [2])
>
> * At least in the beginning, Charly will probably think: "Well, whoever
>will search for triple annotations, he will certainly at least come to the
>idea to search for rdf:Statements. I don't have any clue for what else he
>will search, so I use RDF reification for my encoding. This will be the
>savest path, if any." I would call this argumentation a "maximum likelyhood
>estimation". :)
>
> * And Dave will think: "Well, at least I should search for rdf:Statements,
>because this will be the nearest people will think of, when they encode
>their triple annotations." Again some maximum likelihood estimation.
>
>And an according SPARQL query is pretty simple:
>
> construct { $stmt $p $o }
> where { $stmt a rdf:Statement; rdf:subject me:Alice; rdf:predicate
>foaf:knows; rdf:object he:bob . }
>
>Well, not nice, but it works for Dave, and that is the important point.
>
>And anticipating one of the most likely objections to my argument: I don't
>believe that anyone of the "ordenary semantic web users" out there, who is
>actually interested in putting triple annotations into the SemWeb or
>searching for them, will really be interested in debates about
>"non-existing" or "broken semantics" of RDF reification. I, personally, like
>such debates, but this is in the end just ivory tower bosh. So I won't
>bother these people with questions like: "Hey, don't you know that talking
>about the insertion date of a triple into an RDF store is something
>semantically completely different, than talking about the date since Alice
>knows Bob?" These people do not need the academic world to provide them
>lessons in philosophy. :) What they really need from the academic community
>is a pragmatic tool, which serve their needs, so they can start to do their
>most important job: Filling the SemWeb with content! And RDF reification
>actually provides such a tool, when it is only regarded as a common
>vocabulary, which makes it technically possible to associate an URI to some
>RDF triple. (Sorry, this paragraph has gone a little flamy, but I really
>couldn't resist. ;-))
>
>The third candidate is NamedGraphs. But in order to estimate if this
>approach can be used for the above scenario, I need to know more about it.
>This was the reason why I asked in my last mail "How do named graph data get
>published into the Semantic Web?". If it is (with reasonabe effort) possible
>for instance to search for the URIs of all NamedGraphs of the form
>
> :g { me:alice foaf:knows he:bob }
>
>then NamedGraphs work equally well like Reification for this purpose,
>because I can then, in a second step, query for all those triples in the
>SemWeb, which have the found NamedGraph's URI as their subject. And
>NamedGraphs would bring this big advantage with them that they can talk
>about more than a single triple (though I have difficulties to see what this
>serves me in my usecase above. Perhaps other people will be able to find an
>example, where searching for annotated "multi-triples" would really make
>sense).
>
>But, we must not conceil that NamedGraphs have a very bad disadvantage in
>comparison with Reification, anyway: NamedGraphs are not a standard. And if
>this approach does not get into RDF, or at least into common use, very soon,
>it will possibly lose its chance to become a player at least in the above
>scenario.
>
>/This/ will of course only be a topic /if/ the above scenario is relevant at
>all. Because my whole argumentation pro RDF reification depends on the
>estimation, that the above scenario is a really relevant usecase (of course
>with mashup and search services instead of Charlies and Daves :)). If this
>is not the case, then I won't speak for RDF reification any longer, because
>I then see no real use for it anymore. (At least, until another scenario
>comes to my mind ;-)).
>
>So what do you think?
>
>
>Cheers,
>Michael
>
>[1] http://sites.wiwiss.fu-berlin.de/suhl/bizer/ng4j/semwebclient/
>[2] http://www.topbraidcomposer.com/
>
>--
>Dipl.-Inform. Michael Schneider
>FZI Forschungszentrum Informatik Karlsruhe
>Abtl. Information Process Engineering (IPE)
>Tel : +49-721-9654-726
>Fax : +49-721-9654-727
>Email: Michael.Schneider@xxxxxx
>Web : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
>
>FZI Forschungszentrum Informatik an der Universität Karlsruhe
>Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
>Tel.: +49-721-9654-0, Fax: +49-721-9654-959
>Stiftung des bürgerlichen Rechts
>Az: 14-0563.1 Regierungspräsidium Karlsruhe
>Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
>Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
>
>
>
>--
>Paola Di Maio
>School of IT
>www.mfu.ac.th
>*********************************************
>
>_________________________________________________________________
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
> (07)
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670 (08)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (09)
|