W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > May 2008

(Answer #2) Re: ISSUE-120: Ambiguous Situation with nested @rel where inner @rel is neither CURIE nor link type

From: Ivan Herman <ivan@w3.org>
Date: Sat, 10 May 2008 19:26:59 +0200
Message-ID: <4825DAE3.1040708@w3.org>
To: Mark Birbeck <mark.birbeck@x-port.net>
CC: Shane McCarron <shane@aptest.com>, public-rdf-in-xhtml-tf@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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 May 2008 17:27:37 GMT