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

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
>
>
>
>



-- 
 Mark Birbeck

 mark.birbeck@x-port.net | +44 (0) 20 7689 9232
 http://www.x-port.net | http://internet-apps.blogspot.com

 x-port.net Ltd. is registered in England and Wales, number 03730711
 The registered office is at:

 2nd Floor
 Titchfield House
 69-85 Tabernacle Street
 London
 EC2A 4RR

Received on Saturday, 10 May 2008 15:36:10 UTC