- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 18 May 2007 21:58:00 -0700
- To: Chris Mungall <cjm@fruitfly.org>
- Cc: public-semweb-lifesci <public-semweb-lifesci@w3.org>
>On May 17, 2007, at 8:43 AM, Pat Hayes wrote: > >>>On 17 May 2007, at 05:13, Chris Mungall wrote: >>>[snip] >> >>>>The only support I'd want would be some behind-the-scenes >>>>optimising away of the fact I have 4n triples when a single 3-ary >>>>predicate would do (but hey, again, as it's RDF anyway, I need at >>>>least 4 triples for each type-level statement). >>>[Bijan wrote:] >>>Jena, to my recent surprise, does this. You can even get some >>>syntax joy by using an id on the property element so long as you >>>are ok with the triple *also* being asserted. >>[Pat wrote:] >>Presumably it could be asserted in a different graph, however. I >>don't think that the assertion issue is a big one for metadata >>applications like this, as one is presumably (?) only wanting to >>put metadata onto triples that are in some extant graph out there, >>i.e. that have been asserted somewhere. >> >>(BTW, this whole discussion is predicated on the (IMO naive) >>presumption that publication is tantamount to assertion. Part of >>the motivation for the named graph proposal was to remove this >>presumption and make assertion (and other possible propositional >>attitudes) explicit, so that one graph could deny another or cast >>doubt upon it or agree with it, etc.. Then mere publication is not >>assertion, and this issue goes away.) > >In most translations to RDF/OWL we tend to make the naive >overstatement and assume publication (in the sense of web >publication of the triples, not the original scientific publication >of course) of course > is assertion. Yes, this is implicitly assumed by most users. Or it might be better to say, lacking any way to assert, we presume that unqualified publication is intended to be an assertion. Except, of course, in cases where it obviously isn't, as for example purely tutorial ontologies or examples published to illustrate bad ontology-writing style. Assertion in practice has to be determined by pragmatic ad-hoc criteria. >I'm not sure how NGs are more expressive than reification when it >comes to doubt/agreement? NGs as such just provide a way to give a name to a graph: reification doesn't even do that much. But the NG proposal had other aspects, including a detailed suggestion for publishing secure (digitally signed) 'warrants' which could encode any attitude towards another graph. The usual case of publish=assert becomes then a graph which is a warrant graph which asserts itself, which could be done to a normal RDF graph by adding three (or perhaps it was four) special triples to it. And expressing doubt, agreement, a claim that this graph supercedes that graph which is now deprecated, etc., can be done within the same general framework, since the 'assertion' is a property name in the warrant, and any property can be used. >>>>Though support in other syntaxes like SPARQL would be nice, and >>>>presumably easy to layer on, perhaps in some intermediate >>>>representation. >>> >>>I think it would be a good and wise thing at this juncture to step >>>back and consider viable alternatives that are well designed for >>>one' problem space. I think it's still possible to make a switch, >>>but every project that falls back on reification because it's >>>"standard" enshrines it a bit more. >> >>Well, we agree there. I think reification is clunky. What RDF needs >>is a general way of referring to pieces of its own syntax. The rest >>is then easy, and there can be many flowers blooming. Its not >>enough to be able to describe the syntax: you also need to be able >>to associate an identifier with a piece of extant syntax. >>Reification does the former, but not the latter. > >But there is nothing to stop people assigning URIs instead of using >bNodes is there? Not at all, but there is no standard way of 'assigning', ie making a URI be the identifier of an RDF graph, other than its having the http GET relation to an RDF document. Pat > >Chris > >>Pat >> >>> >>>Cheers, >>>Bijan. >> >> >>-- >>--------------------------------------------------------------------- >>IHMC (850)434 8903 or (650)494 3973 home >>40 South Alcaniz St. (850)202 4416 office >>Pensacola (850)202 4440 fax >>FL 32502 (850)291 0667 cell >>phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Saturday, 19 May 2007 04:58:15 UTC