Re: rdfms-syntax-incomplete

I'm agnostic about whether we should do this, but if we do the approach 
seems mostly OK to me.  I think it's better than the _:x form of 'URI' 
because this provides a very clear syntactic marker in the XML.

To test my understanding:

   _:a ex:prop1 _:b .
   _:a ex:prop2 _:b .
   _:c ex:prop3 _:a .

could then be:

<rdf:Description rdf:node="_:a">
   <ex:prop1 rdf:node="_:b" />
   <ex:prop2 rdf:node="_:b" />
</rdf:Description>
<rdf:Description rdf:node="_:c">
   <ex:prop3 rdf:node="_:a" />
</rdf:Description>

?

Two comments:

(1) I think we'd need to be careful about what constitutes "file scope" -- 
not all RDF is contained in files.  I think we could specify a document 
scope for web resources (a complete representation that you get when 
dereferencing a URI), which covers files via the file: uri scheme, then 
note that applications that obtain RDF in different ways must specify the 
scope of any node identifiers used.  (e.g. CC/PP protocol.)

(2) I think we'd need to say something about combining graphs with these 
node identifiers;  i.e. that renaming must be performed.

(3) Say explicitly that within a scope, any node identifier can be changed 
throughout to any other identifier not used in that scope without changing 
the semantics.

#g
--

At 07:48 PM 7/16/02 +0100, Jeremy Carroll wrote:


>Proposal in brief:
>
>- use attribute rdf:node to associate node identifiers with blank nodes.
>- file scoped identifier.
>- any XML string is legal blank node identifier.
>
>Full resolution:
>- reopen issue rdfms-syntax-incomplete
>- add an attribute rdf:node to the RDF/XML syntax.
>- modify the syntax to permit rdf:node in place of rdf:about.
>- such a use associates the value of the attribute as a file scoped
>identifier for the blank node
>- modify the syntax to permit rdf:node in place of rdf:resource.
>- such a use associates the value of the attribute as a file scoped
>identifier for the blank node
>- any two blank nodes arising from the same RDF/XML file with the same
>identifier are the same blank node
>- action syntax editor to update the document to reflect this
>- rdf:node is not permitted as an element name in RDF/XML
>- action jjc to produce test cases
>- action daveb to update rdfms-names-use to reflect rdf:node
>- close issue
>
>
>======
>
>The chair was keen that we avoid too much discussion. I would like to
>highlight the choicepoints.
>
>+ use of attribute rather than pseudoURI
>
>One possibility was to use "_:label" in place of urirefs on the rdf:about
>and rdf:resource attributes. People said they did not like this idea. It
>would have less clarity but greater backward compatibility.

I think this way is safer.

>+ use of file scope rather than global scode node identifiers
>
>The scope of the identifiers is the same as the scope of identifiers in
>N-triples, i.e. the file. Some use cases point to a need for global scope
>blank node identifiers (e.g. talking about a node within a graph for later
>updates to the graph). This seems to me to be a separate issue, and
>addressing it would constitute a greater change to RDF. (global scope  means
>world-wide, like uris).

I think I prefer your way (being explicit about the scope), it makes it 
clearer that node identifiers are different than URIs.

>+ use of one attributes for both subject and object position rather than
>two.
>
>The current syntax uses two attributes for URI refs. rdf:about on typed
>nodes and descriptions and rdf:resource on property elements. Since these
>two contexts are distinct there is no ambiguity in using the same attribute
>name for both. It may be less confusing to have rdf:aboutNodeIdentifier and
>rdf:resourceNodeIdentifier for the two different roles.

Eitherv way works for me.

Two identifiers might be more obvious, with a clearer relationship to 
existing label attribute roles.

>+ choice of a short attribute name
>
>rdf:node seemed about the shortest clear name for the attribute.

We could discuss this endlessly.  I think short names are good, but not 
essential.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 16 July 2002 20:16:58 UTC