- From: Ivan Herman <ivan@w3.org>
- Date: Sat, 10 May 2008 19:26:59 +0200
- To: Mark Birbeck <mark.birbeck@x-port.net>
- CC: Shane McCarron <shane@aptest.com>, public-rdf-in-xhtml-tf@w3.org
- Message-ID: <4825DAE3.1040708@w3.org>
Actually... I just realized that what I wrote (as a possible solution) in http://www.w3.org/mid/48247ACC.6050602@w3.org is stupid and wrong. (It generates an extra BNode unnecessarily.) Sorry about that. Thinking about it again, maybe Ben's remark is the best. Maybe the only change we should do is in #4 of the processing steps, which comes into effect if there is no @rel/@rev attribute at all, regardless of the validity of the the attribute's value. The validity issue comes into play when triples are generated into the triple store, more exactly that no triples should be generated if the value is invalid. I do not have the syntax document at hand at the moment (sorry about that, I am not on my usual environment) but hopefully that is made clear somewhere in the text... (ie, that triples are generated only if the s,p,o values are valid URI-s or bnodes or literals when allowed... of course, this raises the issue of Shane on what constitutes a valid URI... sigh...) ivan Mark Birbeck wrote: > Hi all, > > Sorry for the delay in providing some input, but I've been at XTech this week. > > Shane is definitely correct that the *intention* was that unrecognised > @rel/@rev values should not affect processing in any way, but no > triples should appear in the *default* graph. > > Recall that we have agreed for a long time now that unrecognised > values could appear in other graphs, so we certainly don't want to > mess up processing. > > For example, let's say that we have this: > > <div about="#ivan"> > <div rel="foaf:knows"> > <div about="#ben" rel="foaf:knows" resource="#shane"></div> > </div> > </div> > > We know that this means that Ivan knows Ben, who knows Shane. > > Now, if we add something from another vocabulary--perhaps the XFN > microformat--the intention is that the parser is free to put those > into another graph if it wants to: > > <div about="#ivan"> > <div rel="foaf:knows met"> > <div about="#ben" rel="foaf:knows met" resource="#shane"></div> > </div> > </div> > > So that's the first point; when I used language like "should act is if > it's not there", this is the effect I wanted to achieved. > > Now, let's remove the first FOAF value: > > <div about="#ivan"> > <div rel="met"> > <div about="#ben" rel="foaf:knows met" resource="#shane"></div> > </div> > </div> > > We still want the *default* graph to contain 'Ben knows Shane', so we > certainly don't want to stop processing when we hit the @rel="met". > (Some other graph might also contain 'Ivan met Ben, who met Shane', > but that is processor-specific; we decided before that the default > graph should *not* contain that.) > > Finally let's remove the second FOAF value: > > <div about="#ivan"> > <div rel="foaf:knows met"> > <div about="#ben" rel="met" resource="#shane"></div> > </div> > </div> > > We still want the first triple about Ivan knowing Ben to be completed, > even if there is nothing in the default graph about Ben meeting Shane. > (As before 'Ben met Shane' could be in some other graph, though.) > > Whilst I don't think everything I have just described is explicit, I > think I could definitely back it up from discussions we've had (and > Shane is also saying that he thinks this was the intent). > > So the question should hopefully be only about the amibiguity, and I > think it arises in the phrase that Ivan and Shane have drawn attention > to, about a "valid @rel or @rev"; I think Ben pointed out that this > should really just be about the *presence* of @rel and @rev, rather > than what it contains, since a processor is free to handle values that > are not in our spec, as long as they don't appear in the default > graph. > > So I'll look at proposing some wording. > > Regards, > > Mark > > 2008/5/9 Shane McCarron <shane@aptest.com>: >> >> >> Ivan Herman wrote: >> >>> Shane, >>> >>> I am not sure that step 10 is relevant in our discussion. What I mean is: >> step 10 is of course valid, but what it says is that it would complete those >> triples with [new subject] (if non-null). [new subject] is established in >> steps 4 or 5, depending on whether @rel/@rev have a valid URI set or not. >> I agree that step 10 is not relevant to this discussion. I was conflating >> two issues. Sorry! >> >> >>> Back to the previous issue... Ie, I am sorry, I still do not believe my >> interpretation is wrong...:-( >>> I tried to look at the possible changes if we want to achieve what Ben >> asks for. Here is one way, maybe: >>> #4 comes into effect if _no_ @rel/@rev are present, regardless of whether >> the value is valid or not >>> There is a #4a which comes into effect if @rel/@rev is present but they >> contain no valid URI-s; in which case the [new subject] is set to @about or >> a new BNode >> I believe this is what Mark intended, and it enables the (edge) case that >> you can stop chaining by inserting an empty rel, which was something we had >> discussed at one time. >> >> >>> #5 comes into effect otherwise >>> >>> Hm. Is such a change editorial or does it send us back to LC2? >>> >> I think it is certainly editorial. I am not certain that it makes Ben or >> Mark happy though. I personally don't care what the answer is. I would >> also be happy with changing text in section 5.4.3 by adding to the end of >> the conditions "Regardless of the datatype of the attribute, if evaluation >> of the attribute value for CURIEs and URIs results in no valid URIs, a >> conforming processor MUST behave as if the element has no specification of >> the attribute (e.g., as if there is no entry for the attribute in the DOM >> tree at all)." >> >> -- >> Shane P. McCarron Phone: +1 763 786-8160 x120 >> Managing Director Fax: +1 763 786-8180 >> ApTest Minnesota Inet: shane@aptest.com >> >> >> >> > > > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Saturday, 10 May 2008 17:27:36 UTC