- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Mon, 29 Apr 2002 11:07:17 +0100
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: RDF Core <w3c-rdfcore-wg@w3.org>
Without wishing to hijack this debate, in some recent work of mine I have noted a possible motivation for dark triples; see http://www.ninebynine.org/RDFNotes/RDFForLittleLanguages.htm#xtocid137228 [[ 7.4 Implications for "dark triples" As I write this, the RDF core working group has been giving some consideration to "dark triples" (i.e. unasserted triples) in RDF models. Using RDF graphs to encode my "little languages", I have no idea if the corresponding subgraphs are satisfiable in the RDF model theory [10]. Practically, this doesn't matter for my applications: they work fine. But is there a problem lurking if the same RDF data is used by advanced reasoners that make full use of the RDF entailments sanctioned by the model theory? This uncertainty would be banished if the RDF core language explicitly recognizes dark triples, and provides a syntactic or other mechanism to designate certain statements as "dark triples". ]] #g -- At 11:23 AM 4/26/02 +0100, Brian McBride wrote: >Hi Folks, > >The SW coordination meeting discussed webont's request for dark >triples. We had a good conversation, everyone is basically in agreement. > >The recorded action in the minutes > > http://lists.w3.org/Archives/Member/w3c-semweb-cg/2002Apr/0039.html > >is > >[[ >ACTION: Guus, to go back to WebOnt subgroup to clarify requirements and >produce something in 2 weeks, deliverables include specific examples, >clarifications, etc. (context http://www.w3.org/2002/04/22-swcg-irc#T17-49-34) >]] > >I understand that 2 weeks may be a bit optmistic, given the web conference >in Hawaii. > >I'm expecting that with this material we'll have a much better >understanding of what the problem is and how it might be fixed. > >My thanks go to the webont folks for this action. > >Brian > > > ------------------- Graham Klyne <GK@NineByNine.org>
Received on Monday, 29 April 2002 07:03:52 UTC