Re: ISSUE-120: Ambiguous Situation with nested @rel where inner @rel is neither CURIE nor link type

Hi Mark, I hope XTech was worth your time...

I also remember these discussions, ie, to make it clear, I do not have 
any problem with the original intention... just let us try to minimize 
the changes in the text:-)

See you soon in San Jose, I guess...

I.

[1] 
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008May/0062.html
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:05:18 UTC