- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Thu, 18 Apr 2002 16:57:20 +0100
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
- Cc: <w3c-rdfcore-wg@w3.org>
At 02:27 PM 4/18/02 +0100, Jeremy Carroll wrote: >In DAML+OIL the syntax of the language is encoded *within* the model rather >than external to the model and merely interpreted in the semantics. > >We see this too in RDFS consider: > >A: ><my:range> <rdfs:subPropertyOf> <rdfs:range> . ><eg:foo> <my:range> <eg:bar> . ><a> <eg:foo> <b> . > >The triples both map into the model, then within the model an RDFS >interpretation is constrained to understand the implicit triple "<eg:foo> ><rdfs:range> <eg:bar> ." and then that in turn constrains the interpretation >of the explicit triple "<a> <eg:foo> <b> ." >If we treated RDFS as merely a syntactic carrier then the fact that there >are not explicit <rdfs:range> triples in the original graph (A) means that >there are no range constraints to consider. In this case, I think its relatively easy to see (even prove) that it is still possible to find interpretations that satisfy the constraints, and support the required entailments. >On WebOnt, Pat and Peter have both asserted that we need to use the RDF >graph as the syntactic carrier and not have such syntax reflected in the >model. But, consider I'll an example of 2-member set equality based on DAML style collections: A rdf:type set . A contains _:a1 . _:a1 first m1 . _:a1 rest _:a2 . _:a2 first m2 . _:a2 rest nil . B rdf:type set . B contains _:a1 . _:b1 first m2 . _:b1 rest _:b2 . _:b2 first m1 . _:b2 rest nil . Here, first and rest are properties with relational extensions that have to satisfy whatever constraints we may need to lay down. So we have: IEXT(I(first) contains { <_:a1,m1> <_:a2,m2> <_:b1,m2> <_:b2,m1> } IEXT(I(rest) contains { <_:a1,_:a2> <_:a2,nil> <_:b1,_:b2> <_:b2,nil> } Furthermore, in this case, to describe A and B as sets, they have the same members and are hence the same set, so anything true of one should also be true of the other. This would lead to constraints like: forall (x) : <I(A),y> in IEXT(x) <=> <I(B),y> in IEXT(x) forall (x) : <y,I(A)> in IEXT(x) <=> <y,I(B)> in IEXT(x) Now, maybe it is possible to find interpretations that satisfy all these constraints. It's not clear to me that such interpretations exist. Further, if they do, it's not clear that they would be sufficiently unconstrained to allow other useful constraints to be satisfied. So it seems to me that even if it's not absolutely theoretically necessary, the detailed semantics of first, rest seem to be rather uninteresting. Thus I think there is utility in being able to place certain parts of the structure "outside" the model theoretic determination of truth, so theorists can focus on the elements whose semantics are of interest. Personally, I find the dark triples approach to language layering to be not-pretty, but I think can see that it does overcome some difficulties. (I still like the idea of subgraphs-as-nodes: it seems more directly useful, but I suppose it also presents greater challenges to implementation in an RDF triple-store.) >... I would like to see >examples where this is not possible (ideally in-charter examples). Because we're talking about a base for extension of RDF, I think in-charter examples will be hard to find. >In practice, nothing will stop people who want to treat the RDF graph >independently of its model theoretic semantics. However, *we* should, IMO, >not be licensing or encouraging such behaviour unless we believe it to be >advantageous. Ha! Maybe that's the rub? If there's a clear way to experiment with RDF without breaking the semantics, people may prefer to do that. If there is none, then people will go ahead and break the syntax and/or semantics anyway. Isn't that exactly what happened with TimBL's N3? (Except, at the time, there was no semantics to break.) >I believe that such behaviour is disadvantageous, because it will mean the >extension mechansim available in RDFS, such as rdfs:subPropertyOf are only >applicable when people are using the model theory and not otherwise. Thus >these extension mechanisms will become a source of confusion, and fall into >disrepute. RDF document authors will need to know whether or not their >application is using asserted or unasserted triples. > >The weasle words turn a normative specification into non-normative advice, >because anyone who doesn't like Pat's excellent work can simply say, "Ah, >but my graph isn't asserted" So the dark triples approach, as I understand it, is to be more precise about indicating unambiguously in some way which triples in a graph are asserted. #g ------------------- Graham Klyne <GK@NineByNine.org>
Received on Thursday, 18 April 2002 12:43:10 UTC