- From: McBride, Brian <bwm@hplb.hpl.hp.com>
- Date: Mon, 29 May 2000 12:47:57 +0100
- To: Graham Klyne <GK@Dial.pipex.com>
- Cc: RDF interest group <www-rdf-interest@w3.org>
Graham, >>One would then have models like this: >> >> >> [this message] ---[was written by]--->Brian >> | >> | >> [asserted by] >> | >> \ / >> Brian > >Indeed. The trouble is, it doesn't fit the RDF model. "[Was >written by]" I must appologise for the diagram not being clear. The intent was to show the whole statement being the subject of the 'asserted by' property which would, I think, be consistent with the RDF model. > >But, being a protocol kind of person (sometimes), I am looking >for how to >*represent* this ("on the wire") to communicate the >information to another >party. > >(Apologies for the laboured repetition here of my previous messages.) > The repitition would be my fault Graham not yours, I think. Perhaps I'm being over careful in trying to be clear. If I can quote from an earlier message of yours: "What I am trying to accomplish is to find a *representation* (as opposed to implementation), within the RDF model (as opposed to serialization), for trust-related information." Perhaps I had misinterpreted this. >>However, the digest approach has the benefit that it can be >represented by >>the currently recommended syntax. > >Atually, I think your approach can be represented reasonably >within the >current *syntax* (BagID, aboutEach, etc.); it's just that in >transferring >to the RDF graph model you have to do a full reification (and >then, it's >not clear how to regenerate the original syntax from the model). My >problem is how to represent this stuff *simply* in the RDF graph model. > Yes, I think you are right. I've been rereading the spec. I'm still finding new stuff in it every time I read it. How about this. So if we imagine that a serialized model represents reification using the ID attribute on production 6.12 of m&s. You can only do that if you are willing have the statement being reified in the model, but that is a limitation that is true of the digest approach as well, I think. So for example (sorry, its rdf serialization): <rdf:RDF> <description about='uri for device'> <foo:screensize ID='ss' >64 32</foo:screensize> <foo:colours ID='clrs'>2</foo:colours> </description> <description about='#ss' foo:context='#context'/> <description about='#clrs' foo:context='#context'/> <description about='#context' foo:assertedBy='Brian'/> </rdf:RDF> That seems simple and clear enough and not too hard to explain. As you pointed out, there is a more compact representation using BagID and aboutEach. For implementation, a parser is needed that has an interface to its 'model' implementation that represents this structure explicitly i.e. the parser inserts a statement into the model with an explicit reified flag, rather than 'doing the reification' and adding the extra 4 statements individually. SiRPAC is the only the parser I have used and doesn't do what is needed here. I don't know what other parsers do. As you have pointed out, many implementations of RDF are able to explicity represent reification of a statement. Given such an implementation, though I haven't written the algorithm, it should not be too hard to spit out an equivalent syntax when serializing. >>The final thought I'd like to add is that when I think about >implementing >>the non-digest approach it seems it would be easy to provide 'full >>reification' with very little, if any, extra work. So I'm >left wondering >>whether the 'overhead' of reification is more perceived than real. > >Two responses: > >(1) as they teach on "management communication" courses and the like, >"perception is everything". If poor perception stops developers from >adopting RDF in all its potential, then the damage is done. >(See Andrea >Chiodi's recent message to this list for an example of this effect.) > I'd agree with that. I'm wondering whether a new mechanism is needed that is intrinsically easier to explain, or a way to explain reification in RDF which raises fewer objections. >(2) the perception becomes reality when one has to communicate >the reified >information between applications. There are real costs of >bandwidth and >protocol processing complexity that get incurred here. > Yup. Do you feel that the digest approach brings significant advantage? >Despite our apparent disagreements, I really think we are on >the same path >here. If I have given you the impression that I am disagreeing, then I need to be more careful with the tone that my messages convey. A lot of the repitition which I sense irritated you was to establish common ground. You have raised an important and interesting question. It is one that I'm pretty confident will be highly relevant to the direction my work is going in too. I'm just trying to explore the options. > >#g > > >PS: I am reminded that there is an alternative model for >semantic graphs >that might allow what you propose, that uses unlabelled arcs >and two kinds >of node for relations and concepts. It's called "Conceptual >Graphs", is >attributed to 1984 work by John Sowa, and is briefly described >in Luger and >Stubblefield's book "Artificial Intelligence" section 8.3. > I'll try to get time to have a look at that. Brian
Received on Monday, 29 May 2000 07:48:08 UTC