[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for separation of subject/predicate and parent-subject/child-subject semantics
Per my action item from Thursday's telecon, following is more about my analysis and proposal for solving the "$has semantics problem" once and for all. *** ANALYSIS *** My first conclusion, on which I think we all agree, is that while +a+b might imply +a/+b and vice versa, that does not mean that: a) they have the same semantics, or b) that they identify the same XDI graph. Indeed, since one is an XDI subject and the other adds an XDI predicate, by definition they cannot identify the same XDI graph. To illustrate in English, most English verbs can be made into nouns by putting them in their infinitive form (“to be”, “to run”, “to shout”). But “run” and “to run”, while clearly linked semantically, do not have the same meaning. They cannot be interchanged with each other. Thus my second conclusion is that none of the three XDI graph examples we were discussing on our telecon two weeks ago were in fact equivalent. They were each different XDI graphs that had similar but not identical semantics. My third conclusion is that this means that we do in fact need clearly distinguished ways of semantically and syntactically of expressing that an XDI subject (e.g., +a) : 1) has a child subject (e.g., +a+b), and 2) has a predicate (e.g., +a/+b). My fourth conclusion was that this is the problem we have been struggling with for the last year: by using $has (with or without variants like $has$a) to express both parent subject/child subject relationships (+a+b) and subject/predicate relationships (+a/+b), we have wrapped ourself in a classic Gordian knot. *** PROPOSAL *** Once the problem was framed this way, it became much easier (for me anyway) to see that a clean solution would be to dedicate the $has predicate to only one semantic – either the parent subject/child subject relationship or the subject/predicate relationship. Of those two options, I strongly prefer dedicating the $has verb to expressing the subject/predicate relationship (+a/+b), since this is the simpler and more intuitive to understand, and mirrors the semantics of the $a predicate, which expresses predicate/object relationships. If $has is dedicated to that expression, then we simply need a different predicate (or set of predicates) to express parent subject/child subject relationships. For that, an obvious answer is to use XRI delimiters as predicates. This is intuitive since it is syntactically required to have a delimiter between XRI subsegments, and each of the six XRI delimiters (not counting parentheses for cross-references) has its own XRI-defined "semantics", e.g., * means reassignable identifier, ! means persistent identifiers, etc. So to summarize using +a and +b notation: +a/$has/+b <==> +a/+b +a/+/+b <==> +a+b +a/$/$b <==> +a$b +a/=/=b <==> +a=b +a/@/@b <==> +a@b +a/*/*b <==> +a*b +a/!/!b <==> +a!b +a/()/(b) <==> +a(b) Semantically, it would still be true that +a+b/$is$a/+b (and the inverse that +b/$a/+a+b). And while +a+b would imply that +a/+b is valid, and vice versa, the existence of one in an XDI graph would not imply the existence of the other. So, if =example wanted to do a query to determine if +a+b and +a/+b both existed in an XDI graph, it would be: =example $get / +a $has +b + +b I have been trying out this proposal in sample XDI documents for the past week and it seems to work very well. Please consider and experiment with it and post your thoughts. We'll put it on the agenda for next week's telecon. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]