RE: Agenda for RDFCore WG Telecon 2003-04-11

Probable regrets for today's teleconf, but here are my views on
the issues identified in the aggenda:

> 13: Issue horrocks-01
> 
>   http://www.w3.org/2001/sw/RDFCore/20030123-issues/#horrocks-01
>   
> ACTION 2003-03-14#11 (path) produce words for a resolution to 
> horrocks-01
> 
> We need a formal disposition which I don't think we had 
> before.  Therefore
> 
> Propose:
> 
> WG not accept horrocks-01 for reasons stated in 
> 
>   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0110.html

Yes.

> 15: Namespace change
> 
> http://www.w3.org/2001/sw/RDFCore/20030123-issues/#efth-01
> 
> per jjc proposal:
> 
>   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0155.html
> 
> [[
> Considering that:
> 
>    o the WG, have in multiple editions of WD's indicated its 
> intention to 
> not to change the URI REFS for the RDF and RDFS namespaces
> 
>    o the WG explicitly requested feedback on this intention
> 
>    o very little negative feedback has been received
> 
>    o there is significant cost and complexity in changing the 
> namespace URI 
> REFs
> 
> the RDFCore WG resolves
> 
>    o not to change the URI REFS for the RDF and RDFS namespaces
> 
>    o to ACTION the document editor's to make such editorial 
> changes as are 
> required by this decision
> 
> ]]
> 
> 
> See:
>   http://www.w3.org/2001/sw/RDFCore/20030123-issues/

Yes.


> 16: Concepts Issues
> 
> pfps-22, pfps-23:
>    
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0044.html

Yes.

> pfps-16 (revised proposal):
>    
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0045.html

Yes.
 
> williams-01 (revised proposal):
>    
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0107.html

Yes, but would like to see "property" changed to "predicate" in the
first sentence of 3.1 to remain consistent with the traditional
terminology for describing the components of a triple/statement.
I wouldn't be opposed to having "property" in parentheses following
"predicate". I.e. "predicate (or property)", etc.

> RDF fragment text, and revision:
>    
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0093.html
>    
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0123.html 
> 
> I'm a bit confused by the email traffic.  Are there specific proposals
> for the WG to consider?

As an aside, which may simply be out of line and justifiably ignored
given where we're at in the process, but I've come to completely 
dislike this explanation of the RDF treatment of fragment identifiers.

Whether one posits that the base URI denotes adocument or any
arbitrary resource for which the RDF/XML is a representation,
there is no constraint whatsoever that the resource denoted by
a URIref have any semantic relationship to the resource denoted
by the base URI, much less be a "view" or "fragment" of the
resource denoted by the base URI.

This is simply just plain wrong, and we shouldn't say it.

It is also self-contradictory in that the spec first says that the
URIref denotes a fragment or view of the document denoted by the 
base URI, but then goes on to say that the URIref can denote anything, 
not restricted in any way to the document.

Either the resource denoted by the URIref is or is not related to 
the document.

Having a resource denoted by a URIref as a view or fragment of a
document seems to preclude it denoting e.g. a mythical unicorn.
If the base URI denotes an RDF/XML schema, how is a mythical
unicorn in any stretch of the imagination a "view" or "fragment"
of an RDF/XML schema? It's not. And that's because we're talking
about meaning, not syntax. Fragment identifiers were intended
to be interpreted syntactically, not semantically. We're in new
territory with RDF and we need to be careful about presuming that
the legacy architecture is always correct. In this case, it's not.

The fact of the matter is that the interpretation of URIrefs by
RDF has *nothing* whatsoever to do with representations or physical
documents and we should simply say so. 

So, OK to say that we presume the base URI has a representation
that is an RDF/XML instance, but then we should say that, the
treatment of fragment identifiers in terms of RDF/XML is that
there is *no* special relation presumed between the resources
denoted by the URIref and the base URI. Period.

There isn't even any presumption that if the base URI *does* in
fact have an RDF/XML representation that it will contain any
statements whatsoever with a given URIref as its subject. One
can ground a URIref in a base URI in any RDF/XML instance
whatsoever, using rdf:about rather than rdf:ID.

To posit that there is any kind of semantic relationship, insofar
as RDF is concerned, between a URIref and its base URI is simply
wrong, so let's not do it.

If all we can do at this point is remove the discussion about
"views" and "fragments" of RDF/XML documents, then at least let's
do that. We can then re-address this issue in a Note.

> 17: documents at end of RDF(S) namespace URI's
> 
>   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0012.html

I propose that our response to this issue should be 

[[

The WG has no authority to modify these documents, so we cannot promise 
any changes or corrections to those documents in conjunction with the last 
call process. In any case they should not be considered to be a part of the RDF
specifications and therefore are not normative insofar as the RDF specs
are concerned. 

However, given that the documents do have a clear relationship to the RDF 
specifiations via the standard namespaces defined for the RDF vocabularies, 
the WG will work with the relevant parties at the W3C with the goal (albeit
not the guaruntee) of achieving the following:

1. Ensure the two documents at the URIs as given in the drafts
   are rdf-valid, rdfs-valid from the RDF Semantics WD point of view.

2. Update the documents at the two URIs to fully reflect the normative
   portions of the revised RDF specifications pertaining to the RDF
   vocabulary.

]]

Cheers,

Patrick

Received on Friday, 11 April 2003 03:18:12 UTC