Re: rdfms-nested-bagIDs was (Re: RDF Issue)

On Thu, 2002-03-21 at 18:01, Jeremy Carroll wrote:
> 
> Hi Pierre-Antoine
> 
> it appears from your message:
> 
> http://lists.w3.org/Archives/Public/www-rdf-comments/2002JanMar/0214.html
> 
> that the WGs resolution of the nested bagIDs issue was insufficiently clear.

My question was initially about the following configuration:

<rdf:Description rdf:about="#a" rdf:bagID="bag1">
  <some:prop rdf:ID="st1">
    <rdf:Description rdf:about="#b" bagID="bag2">
      <some:otherProp rdf:ID="st2"> A literal </someOtherProp>
    </rdf:Description>
  </some:prop>
</rdf:Description>

Obviously, any parser should create a bag <bag2> containing the reified 
statement <st2>, and a bag <bag1> containing the reified statement
<st1>.

I just wanted to know if <bag1> shoudl *also* contain <st2>, or in other
words, should inner bagIDs *override* (or hide) outer ones.

I understand the decision of the WG to be a "yes" to the question above.

> In particular your suggestion:
> 
> > So we could propose an idiom like rdf:bagID="",
> > overriding the outer bagID but creating no additional bag.
> 
> is, if I have understood you correctly, the default behaviour.
> That is reifications of the more deeply nested triples that could go into an
> additional bag *never* go into the outer bag.

The question you mention came from an idea I had by reading the decision
of the WG:
adding the 'rdf:bagID="bag2"' attribute to the inner 'Description'
element has actually two effects:
1- creating a new bag of reified statements (namely, <bag2>)
2- preventing the statement inside this element to be added to <bag1>

Hence my second question: is there a way to achieve effect #2 *without*
effect #1? I don't think there is any for the moment.
The idiom I proposed does not look so good, since the empty string can
in fact be interpreted as a relative URI.

But anyway, this was just a suggestion. I'm not even sure some people
would find it useful... I'm not even sure I do :)

  Pierre-Antoine

Received on Monday, 25 March 2002 05:18:43 UTC