paola.dimaio@xxxxxxxxx wrote:
> quadruples, next gen semantics perhaps?
>
Conventional FO logics allow for arbitrary length tuples, so quadruples
are nothing new. ISO Common Logic allows for variadic tuples in a single
relation. The topic is discussed in the W3C/RDF community at some length
only because RDF is treated there as a 'basic' syntax, and official RDF
at present is restricted to triples. Various extensions of RDF in actual
use, however, amount to a quad-based syntax (N3, Named graphs and
various quad-store systems such as the Oracle RDF implementation). This
is all to do with a reductive syntax: it has nothing particularly to do
with semantics. (01)
The RDF idea of reification, and the corresponding notion of naming an
ontology with a name that can be used in other ontologies, is relatively
new. Again, the ISO Common Logic specs give a fully-worked-out semantics
for this idea, one which generalizes the treatment in the named graph
proposal. (02)
Pat (03)
> 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
>
>
>
> (04)
_________________________________________________________________
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 (05)
|