# $Id: RDFConceptIssues.n3,v 1.23 2002/11/29 18:27:33 graham Exp $
#
# RDF Concepts and Abstract Syntax document
# Issues list
#
# This is being used as a use-case/testbed to generate an RDF schema
# for document issue tracking. This file will be processed by variations
# of the SemaFor software to generate status reports for general use.
#
# In time, the information should be lodged in a database as a Jena model,
# rather than as a flat file. Meanwhile, flat-file N3 is a user interface
# I can handle...
#
#--------+---------+---------+---------+---------+---------+---------+---------+
#
# Copyright (c) 2002, G. KLYNE
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. The name of the author may not be used to endorse or promote products
# derived from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
# OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#--------+---------+---------+---------+---------+---------+---------+---------+
# $Source: /Users/graham/cvs/cvsweb/ninebynine.org/docs/wip/DocIssues/RDFConceptIssues.n3,v $
# $Author: graham $
# $Date: 2002/11/29 18:27:33 $
# $Id: RDFConceptIssues.n3,v 1.23 2002/11/29 18:27:33 graham Exp $
#--------+---------+---------+---------+---------+---------+---------+---------+
# 1 2 3 4 5 6 7 8
@prefix rdf: .
@prefix rdfs: .
@prefix foaf: .
@prefix dc: .
@prefix iss: .
# About this document:
<> rdfs:label "RDF Concepts and Abstract Syntax - issues" ;
iss:about ;
dc:author "Graham Klyne" ;
rdfs:comment
"""
List of issues and current status for the document
Resource Description Framework (RDF):
Concepts and Abstract Data Model
working draft.
""" .
# About the target document editors
foaf:mbox ;
foaf:name "Graham Klyne" ;
foaf:initials "GK" .
foaf:mbox ;
foaf:name "Jeremy Carroll" ;
foaf:initials "JJC" .
# About the RDF Concepts document:
rdf:type iss:Document ;
iss:name "RDF-Concepts" ;
rdfs:label "RDF Concepts and Abstract Data Model" ;
iss:cite ;
iss:editor ;
iss:editor ;
iss:history # document history
(
[ iss:status iss:W3CWorkingDraft ;
iss:when "2002-08-29" ;
iss:cite ;
rdfs:comment
"""
First official working draft of document.
""" ]
) ;
rdfs:comment
"""
The Resource Description Framework (RDF) is a data format
for representing metadata about Web resources, and other
information.
This document defines the abstract graph syntax on
which RDF is based, and which serves to link its XML
serialization to its formal semantics.
It also describes some other technical aspects of RDF
that do not fall under the topics of formal semantics,
XML serialization syntax or RDF schema and vocabulary
definitions (which are each covered by a separate
document in this series).
These include: discussion of design goals, meaning of
RDF documents, key concepts, character normalization and
handling of URI references.
""" ;
### Document issues follow ###
################ Issue 001 ################
iss:issue
[ iss:name "001-Editorial" ;
rdfs:label "Editorial comments" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Patrick Stickler" ;
foaf:initials "PatS" ] ;
iss:raisedDate "2002-08-08" ;
iss:raisedCite ;
iss:resolvedDate "2002-10-25" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-08-08" ;
iss:cite ;
rdfs:comment
"""
Comments raised to WG prior to initial WD publication,
but not folded in to the document.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
iss:owner ;
rdfs:comment
"""
[GK] Editorial fixes clearly in GK's text.
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-26" ;
#iss:cite ;
rdfs:comment
"""
Item 1: added comment in section 1.
Item 2: instead: "RDF is a member of the family of languages that use XML, ..."
Item 3: instead: "Support use of XML schema datatypes"
Item 4: I think "not covered" says it all here. In connection with
the first part of the sentence I think its perfectly strong enough.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
Changes folded into publicly accessible document.
""" ]
) ;
iss:sectionRef ;
iss:sectionRef ;
iss:sectionRef ;
iss:sectionRef ;
rdfs:comment
"""
1. In section 1, it says "RDF is based on a graph syntax, which is
typically serialized using XML.". I think it would be good to
make clear here that the RDF graph syntax is not equivalent
to the XML infoset, and that the XML serialization really
constitutes a "recipe" for constructing the conceptual graph.
Alot of folks seem to get confused when the RDF graph doesn't
mirror the RDF/XML or visa versa, so making this clear up front
may be helpful.
2. In section 2, it says "RDF builds on XML". I don't think
this is accurate. RDF uses XML to serialize its graph structures,
but is not an extension of XML, but only includes an application
of XML.
3. In 2.2, a stated design goal is "Use XML schema datatypes". I
think it would be better to say "Support the use of XML Schema
datatypes". Otherwise, it may be taken to imply that XML Schema
datatypes are integrated with or into RDF directly, which they
are not (and IMO should not be). Ahh, yes, I see that this is
clearer in the discussion of this bullet item, but still, perhaps
the bullet item could be clearer.
4. In 2.4.3, perhaps "are not covered by this recommendation."
could be expressed more strongly as "are not licensed by this
recommendation for interchange of RDF graphs".
""" ] ;
# -- End of issue --
################ Issue 002 ################
iss:issue
[ iss:name "002-InconsistentAssertions" ;
rdfs:label "Inconsistent assertions incompatible with MT" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Peter F. Patel-Schneider" ;
foaf:initials "PFPS" ] ;
iss:raisedDate "2002-09-02" ;
iss:raisedCite ;
iss:resolvedDate "2002-10-25" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-02" ;
iss:cite ;
rdfs:comment
"""
The statements about inconsistent assertions read as being
incompatible with the Model Theory document.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
iss:owner ;
rdfs:comment
"""
[GK] Editorial fixes clearly in GK's text.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-09-10" ;
rdfs:comment
"""
[GK] I think the text needs to be clearer about logical
inconsistency in RDF assertions (not possible), and
inconsistency of such assertions with real-world users
expectations (possible).
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-26" ;
#iss:cite ;
rdfs:comment
"""
Revised wording:
"A consequence of this is that RDF cannot prevent anyone from
making assertions that are nonsensical or inconsistent with
the world as people see it, and applications that build upon
RDF must find ways to deal with incomplete and conflicting
sources of information."
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
Comments folded in to publicly accessible document.
""" ]
) ;
iss:sectionRef ;
rdfs:comment
"""
I just took a quick look at the new WD.
On thing that jumped out at me was:
Section 2.2.6 ... RDF cannot prevent anyone from making ... inconsistent
assertions, and applications that build upon RDF must find
ways to deal with conflicting sources of information.
Contrast this with the RDF MT document:
Section 2 ... This means that there is no such thing as an inconsistency
or a contradiction in RDF.
I'm pretty sure that both documents cannot be correct.
""" ] ;
# -- End of issue --
################ Issue 003 ################
iss:issue
[ iss:name "003-ModelTheory" ;
rdfs:label "Problems with introduction to model theory" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Jerome Euzenat" ;
foaf:initials "JE" ] ;
iss:raisedDate "2002-09-04" ;
iss:raisedCite ;
iss:resolvedDate "2002-10-25" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-04" ;
iss:cite ;
rdfs:comment
"""
Concerns raised with the introduction to concepts of formal
semantics.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
iss:owner ;
rdfs:comment
"""
[GK] Editorial fixes clearly in GK's text.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-09-05" ;
iss:cite ;
rdfs:comment
"""
[GK] Pat Hayes' response to this comment.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-09-06" ;
iss:cite ;
rdfs:comment
"""
[GK] Jerome Euzenat response to Pat Hayes.
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-26" ;
#iss:cite ;
rdfs:comment
"""
Revisions, based in part on Pat Hayes' response (thanks Pat!):
1. Replace "certain meanings..." with "formal meanings...".
2. Replace "'world'" with "set of possible 'worlds'", so that the sentence
reads: "Model-theoretic semantics assumes that a language refers to a set of
possible 'worlds', ..."
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-27" ;
rdfs:comment
"""
The wording has been refined through further exchanges with Pat Hayes.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
Comments folded in to publicly accessible document.
""" ]
) ;
iss:sectionRef ;
rdfs:comment
"""
about the "Resource Description Framework (RDF):Concepts and
Abstract Data Model" document, I have comments about one minor part
(viz. 2.3.1 Formal semantics):
| To serve this purpose, certain meanings of RDF statements must
| be defined in a very precise manner
why "certain" and which ones?
>Model-theoretic semantics assumes that a language refers to a
>'world', and describes the minimal conditions that such world must
>satisfy in order to assign an appropriate meaning for every
>expression in the language.
"a language refers to a 'world'" is at least misleading:
- this is rather the assertions in the language which refer to the world.
- the word "a" here could lead the reader to equate one language or
one set of assertion to one world, though the purpose of model theory
is not to tie the assertion to one world but rather to consider all
the possible worlds.
I offer the replacement:
"Model-theoric semantics defines the meaning of expressions in the
language through a mapping (called interpretation) from a language to
worlds. A set of assertions in the language, thus induce constraints
on the acceptable interpretation (called model) of these assertions.
The meaning of an expression is defined with regard to its
interpretation in all the models."
I am sure that this is too technical, maybe reducing this part and
refering to RDF-MT document is an easier alternative.
> A particular world is called an interpretation, so that model
>theory might be better called 'interpretation theory'.
Not accurate: an interpretation is a mapping from the language to the
world. Indeed there can be many interpretations mapping to the same
world.
A model of a set of assertions is an interpretation that satifies all
the assertions in the set (i.e., which maps it to the element of a
distinguished subset of the world for being very general, very often
the set { true }). So model theory is well named.
""" ] ;
# -- End of issue --
################ Issue 004 ################
iss:issue
[ iss:name "004-MultiGraph" ;
rdfs:label "Multi graph is not adequately explained" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Jerome Euzenat" ;
foaf:initials "JE" ] ;
iss:raisedDate "2002-09-04" ;
iss:raisedCite ;
iss:resolvedDate "20021118" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-09-10" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-04" ;
iss:cite ;
rdfs:comment
"""
Aspects of multi graph not fully explained.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
iss:owner ;
rdfs:comment
"""
[GK] Editorial fixes clearly in JJC's text.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-11-18" ;
iss:cite ;
rdfs:comment
"""
Citation is Jeremy's response
""" ]
) ;
iss:sectionRef ;
rdfs:comment
"""
Also in 3.5 RDF graph, in the Note:
- RDF Graphs are "node-labeled, edge-labeled directed multi-graphs"
(with no disjointness constraints between node-labels and
edge-labels): the multi- aspect is not in the note (i.e., that there
can be several arcs between the two same nodes -- maybe with
different labels).
""" ] ;
# -- End of issue --
################ Issue 005 ################
iss:issue
[ iss:name "005-Editorial-Concepts" ;
rdfs:label "Editorial comments about concept sections" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Massimo Marchiori" ;
foaf:initials "MM" ] ;
iss:raisedDate "2002-09-04" ;
iss:raisedCite ;
iss:resolvedDate "2002-10-25" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-04" ;
iss:cite ;
rdfs:comment
"""
Editorial comments concerning concepts sections.
Also expresses concern that some of the material tackled is
too difficult, cannot be formalized, and does not belong
in an RDF specification.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
rdfs:comment
"""
[GK] Concerns clearly with GK's text.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-09-10" ;
iss:cite ;
iss:cite ;
rdfs:comment
"""
[GK] Note that most of the difficult issues raised here are
in response to specific comments raised against the
previous RDF specifications. See the issues cited.
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-26" ;
iss:cite ;
rdfs:comment
"""
Material from earlier sections may be moved to other places when the
document set is reviewed as a whole. Until then, I plan to leave it
here so that the material is not lost.

Concerning the discussion of fragment, this was included in response
to a specific issue raised against the document. I've been living with
this explanation for a while now, and feel that the basic ideas are
consistent with RDF usage and with wider URI use in the web.

(No document changes at this time.)
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
No change to the concept sections at this time.
""" ]
) ;
iss:sectionRef ;
iss:sectionRef ;
iss:sectionRef ;
rdfs:comment
"""
First, thanks much for setting this draft out, I think it clears the way to a
finally unambiguous definition of the data model, and solves my previous rants
on the data model part in the MT
(cf. from
http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0107.html :
+ issue of literal information in the semantics
+ "no free meal" for blank nodes (and related instances problem))
provided of course the MT is updated accordingly.
Ideally, the MT might just refer to this draft for any ADM definition :)
Even, it touches the other big issue regarding the Test case drafts, namely
the previosuly erroneous/fuzzy notion of graph isomorphism, cf.
http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0081.html
and
http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0083.html
(incidentally, I think we didn't get a final resolution about the conformance issue
there yet; oh well ;).
Back to the doc, some comments, plus a couple of discussion points (XML literals, fragid's).
*** Sections 1 and 2:
> [[[NOTE: it is anticipated that some of the material in this document may be
> moved to other documents as part of the document review process.]]]
Yes, this is definitely an option: I found the doc very well written, but,
so to say, like it's putting together things of a very different nature: ADM
formal definition, general principles about the semantics, etc.
Mostly, 2.1, 2.2 and 2.3 don't seem to belong to the next part, the ADM
definition. I'll let you figure out how to deal with this. An option might be
to move 2.1, 2.2 and 2.3 to the Primer, for example. Anyway, just a matter
of personal reading tastes.
[...]
*** Section 4.2
Do we really need this? This whole part is made out of linguistic statements
(because, admittedly, the issue is hairy), but so it should be either formalized
(and then, likely put in the MT), or taken out.
Restated: suppose the whole section is striken out: what would change?
I'd suggest RDF stays out of the very hairy fragid's issue for the time being.
""" ] ;
# -- End of issue --
################ Issue 006 ################
iss:issue
[ iss:name "006-Editorial-Syntax" ;
rdfs:label "Editorial comments about syntax section" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Massimo Marchiori" ;
foaf:initials "MM" ] ;
iss:raisedDate "2002-09-04" ;
iss:raisedCite ;
iss:resolvedDate "2002-11-18" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-11-18" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-04" ;
iss:cite ;
rdfs:comment
"""
Various concerns with definition of abstract graph syntax.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
iss:owner ;
rdfs:comment
"""
[GK] Concerns clearly with JJC's text.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-11-18" ;
iss:cite ;
rdfs:comment
"""
Citation is Jeremy's response.
""" ]
) ;
iss:sectionRef ;
rdfs:comment
"""
*** Section 3.2
> Two RDF literals are equal if and only if they are either both XML
> literals and equal or both string literals and equal.
This def is superfluous, and can be cleared out.
*** Sections 3.2.1 and 3.2.2
These defs don't work, because they give in the ADM that XML literals
overlap with RDF literals. This ambiguity was a problem already implicitly
present in the old RDF spec, and never really clarified so far. You need to
make the ADM more fine-grained, and extend their ADM representations
with a flag or so, to make these two sets disjoint (but see also the
next issue).
*** Section 3.2.2
This is a more higher-level issue on XML literals: do we really need to
have them at the ADM data model level? With the ongoing work on data
types, wouldn't it be better to just have string literals as the only
basic datatype here?
I see this is already somehow mentioned in 2.2.5:
> [[[Review this on resolution of datatypes issues]]]
and I would favor to drop them if possible, and just use a generic datatyping
mechanism (otherwhise, the basic ADM gets more complex (as seen above), and risks
to unnecessarily complicate the datatyping mechanism. Anyway, yes, this is
dependant on the final resolution on datatyping.
*** Sections 3.3, 3.4 and 3.5
> A tidy set of nodes is one in which no two nodes have equal labels. A tidy
> set of nodes may have any number of distinct blank nodes
Mmm, do we need to introduce the "tidy" concept (as a name)? It's not
really needed (there are not "untidy" sets used in RDF), and it gives a
longer and more complex def.
So, suggestion: just define the RDF graph in its shortest and simplest way:
: B is an infinite set disjoint from (RDF-Lits U URI-refs)
: An RDF-triple belongs to ((URI-refs U B),URI-refs,(URI-refs U B U RDF-Lits))
: An RDF Graph is a set of RDF-triples.
(note: I'd even say a *finite* set of RDF-triples, but if nobody else cares,
I'm fine with the more general, "non-always-computable" def).
*** Section 3.6
> Two RDF graphs are equal if and only if they are isomorphic
We just need the notion of "isomorphism", so this should be deleted, and
the section renamed accordingly with "3.6 Graph Isomorphism"
(there's no real use to have two names for the same thing).
""" ] ;
# -- End of issue --
################ Issue 007 ################
iss:issue
[ iss:name "007-Meaning-machinery" ;
rdfs:label "Comments on RDF meaning and machinery" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Peter F. Patel-Schneider" ;
foaf:initials "PFPS" ] ;
iss:raisedDate "2002-09-06" ;
iss:raisedCite ;
iss:resolvedDate "2002-10-25" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-10" ;
iss:cite ;
rdfs:comment
"""
Various objections to text dealing with assertions and meaning
in RDF, particularly at the overlap between formal and social
meaning.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
iss:owner ;
rdfs:comment
"""
Most of these comments seem to address GK's text.
Need to check some comments in detail, as precise target
referent isn't immediately obvious.
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-26" ;
iss:cite <003-ModelTheory.html> ;
iss:cite <016-NodeLabels.html> ;
rdfs:comment
"""
1. The phrase "say anything about anything" has been a useful sound-bite,
but I agree is not most appropriate here.
I think saying that "Anyone can make simple assertions about anything"
is close enough for the purposes of this section.

2. What can RDF express? Yes, I got that wrong, misunderstanding the meaning
of "ground fact". I'll try to make 2.2.7 more precise.

3. Yes, "certain meanings of RDF statements" is not the most helpful phrasing.
See issue 003-ModelTheory.

4. Concerning "no machinery for formalizing allowable inferences", the intent
was to say that RDF has no way to express these. I'll change it to:
"with no way to formally express allowable inferences".

5. The matter of node labelling has been separated into a separate issue,
016-NodeLabels.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
Comments folded in to publicly accessible document.
""" ]
) ;
iss:sectionRef ;
iss:sectionRef ;
iss:sectionRef ;
iss:sectionRef ;
rdfs:comment
"""
Some Comments on
Resource Description Framework (RDF):
Concepts and Abstract Data Model
http://www.w3.org/TR/2002/WD-rdf-concepts-20020829/
The title of Section 2.2.6 is misleading at best, and just plain wrong
at worst. RDF cannot ``say anything about anything.'' For example,
it cannot say that every person has at most one parent. So what can
RDF say? Does RDF allow ``universal expression of ground facts'', as
stated in Section 2.2.7? No, RDF cannot say, for example, that Sue or
Ellen is John's sister, or that Sue is not John's sister, or that if
Sue is John's sister then so is Ellen, all of which are ground facts.
Maybe RDF can say atomic ground facts? No, RDF cannot say, for
example that there is an purchase property between John, Susan, and
John's pet rock. Is there any place in the document that correctly
states what RDF can say? Not that I could find, not even the
statement that RDF can say ``assertions of specific properties about
specific named things'' because that ignores unnamed (or blank) nodes
in RDF graphs.
The document says that to support use by automated tools ``certain
meanings of RDF statements must be defined in a very precise
manner''. Does this mean that there are several, possibly different,
meanings of RDF statements?
The document says that the RDF core language has ``no machinery for
formalizing allowable inferences''. What then is RDF closure as defined in
the RDF Model Theory document?
The documents says that many of the nodes in an RDF graph are blank
and some are labelled. Why the differences? Does this mean that
there can be no RDF graphs where all nodes are labelled?
""" ] ;
# -- End of issue --
################ Issue 008 ################
iss:issue
[ iss:name "008-InteractionUnclear" ;
rdfs:label "Interaction between social and formal meanings is unclear" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Dave Reynolds" ;
foaf:initials "DER" ] ;
iss:raisedDate "2002-09-09" ;
iss:raisedCite ;
iss:resolvedDate "2002-10-25" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-09" ;
iss:cite ;
rdfs:comment
"""
Need to clarify text dealing with interaction between social
and formal meaning, particularly with respect to mechanical
inferences.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-10" ;
iss:owner ;
rdfs:comment
"""
[GK] This text is earmarked for reworking.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-09-10" ;
iss:cite ;
rdfs:comment
"""
Try and use Pat Hayes' text and example to illustrate this
more clearly (but changing the subject matter to reduce any
possibility of offence).
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-30" ;
iss:cite <013-Various.html> ;
rdfs:comment
"""
Section 2.3 has been extensively re-worked, incorporating comments from
Pat Hayes and Tim Berners-Lee.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
Comments accounted for in publicly accessible reworked document.
""" ]
) ;
iss:sectionRef ;
iss:sectionRef ;
iss:sectionRef ;
rdfs:comment
"""
Section 2.3.3 is unclear.
In particular the statement:
"Human publishers of RDF content commit themselves
to the mechanically-inferred social obligations."
needs greater clarification.
Is the mechanical inference referred to here solely RDF entailment from the
asserted graph G (as implied by the context of the preceding paragraph)? If so,
that is reasonable since the space of RDF entailments is so limited.
However, without clarification the phrase might be construed to also refer to
entailment based on G together with graphs asserted elsewhere or to the sort of
deduction discussed in the subsequent paragraphs with its mix of social and
logical dimensions and not-demonstrably-valid implementations - that would not
be reasonable!
Section 2.3.2 is also a little problematic in the light of 2.3.3 in that the
"combination of social and technical machinery" for distinguishing assertions
from "other uses (e.g. citations, denials or illustrations)" is not actually
defined anywhere which makes "mechanically-inferred social obligations" extra
worrying.
""" ] ;
# -- End of issue --
################ Issue 009 ################
iss:issue
[ iss:name "009-DatatypingSyntax" ;
rdfs:label "Update abstract syntax to account for datatyped literals" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "RDF Core WG" ;
foaf:initials "RDFcore" ] ;
iss:raisedDate "2002-09-12" ;
iss:raisedCite ;
iss:resolvedDate "2002-11-08" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-11-08" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-09-12" ;
iss:cite ;
rdfs:comment
"""
[GK] Brian's note describing proposed distribution of the datatyped literal
material among working group documents.
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-16" ;
iss:owner ;
rdfs:comment
"""
[GK] Working group accepted proposal. Abstract Syntax is Jeremy's expertise.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-09-30" ;
iss:cite ;
rdfs:comment
"""
The datatyping document whose contents are to be incorporated.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
This document release contains a reworking of the datatyping and abstract
syntax to incorporate this material.

This document contains a significant contribution from Pat Hayes,
Sergey Melnik and Patrick Stickler, under whose leadership was
developed the framework described in the RDF family of specifications
for representing datatyped values, such integers and dates.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
Material incorporated into to publicly accessible document.
""" ]
) ;
iss:sectionRef ;
rdfs:comment
"""
I would like to ask the WG to join me in expressing our thanks for the
monumental efforts that Pat Hayes, Sergey Melnick and Patrick Stickler have
put into the work on datatypes for RDF. The work on datatypes began nearly
a year ago. I don't have the tools to determine how many email messages or
how many document drafts there have been on the subject, but the answer is
"a lot". Hmmm, that looks like a lexical form of ... oh never mind that
for now.
Many others have also contributed to the solution of this problem, but I
felt that we should specifically acknowledge the contributions of the
editors of the WD that is now, not to be.
What matters, is that they have led us to, what I believe, is an excellent
solution and have accepted with exceptional grace that that solution is not
best described in a separate document.
I have an action from the last telecon to ensure that these gentlemen
receive appropriate acknowledgement for their efforts. After consulting
with Eric, I understand that the mechanism for acknowledging specific
contributions to a specification, is to include an appropriate paragraph in
the acknowledgements section of affected documents.
I suggest a paragraph similar to the following (better words welcome) be
included in the primer, syntax, concepts, schema and model theory documents.
[[
The method described in the RDF family of specifications for representing
datatype values such integers and dates, was developed under the
leadership of Pat Hayes, Sergey Melnik and Patrick Stickler.
]]
""" ] ;
# -- End of issue --
################ Issue 012 ################
iss:issue
[ iss:name "012-AssertionConflictingUse" ;
rdfs:label "Conflicting use of the term 'assertion'" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Frank Manola" ;
foaf:initials "FrankM" ] ;
iss:raisedDate "2002-08-23" ;
iss:raisedCite ;
iss:resolvedDate "2002-10-25" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-08-23" ;
iss:cite ;
rdfs:comment
"""
[GK] Frank Manola's message in response to RDFcore WG action 2002-08-23#7
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-09-16" ;
iss:owner ;
rdfs:comment
"""
[GK] Frank's comments relate to text by GK.
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-30" ;
iss:cite <008-InteractionUnclear.html> ;
rdfs:comment
"""
I think these comments have been largely addressed by the reworking per
issue 008-InteractionUnclear: the discussion of social and technical
context is much expended, and the wording in relation to application/rdf+xml
has been somewhat decoupled from discussion of assertions.

In response to Frank's comments, I've added an abbreviated form of his "clown"
example to section 2.3.2.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-10-14" ;
iss:cite ;
rdfs:comment
"""
Frank not entirely happy with proposed revisions.
""" ]
[ iss:status iss:Response ;
iss:when "2002-10-22" ;
iss:cite ;
rdfs:comment
"""
New reworking proposed.
""" ]
[ iss:status iss:Resolved ;
iss:when "2002-10-22" ;
iss:cite ;
rdfs:comment
"""
Frank agrees!
""" ]
[ iss:status iss:Closed ;
iss:when "2002-10-25" ;
iss:cite ;
rdfs:comment
"""
Material incorporated into to publicly accessible document.
""" ]
) ;
iss:sectionRef ;
rdfs:comment
"""
Re:
http://www.ninebynine.org/wip/RDF-basics/2002-08-05/Overview.htm#section-Social
ACTION 2002-08-23#7, FrankM: Propose alternative text for the concepts
and abstract model document to rectify concerns with conflicting use of
"assertion".
To state the problem:
The last sentence but one of Section 2.3.1 says "The RDF model theory
treats RDF as a simple assertional language, in which each triple makes
a distinct assertion...".
The last sentence of the first para of Section 2.3.2 says "A combination
of social (e.g. legal) and technical machinery (protocols, file formats,
publication frameworks) provide the contexts that fix the intended
meanings of the vocabulary of some piece of RDF, and which distinguish
assertions from other uses (e.g. citations, denals or illustrations)."
It seems to me someone might read the first bit as saying "all triples
are assertions" and the second bit as saying "some triples are not
assertions" (e.g., "denals" [sic]), and then wonder what's going on.
The main problem is that the first bit (taken from the model theory) is
taken out of context, since there are a number of caveats elsewhere in
the model theory, e.g., "This only applies to uses of RDF that are
intended to be the assertion of simple propositional content."
Here's my suggestion: basically, add some stuff to the beginning of the
first paragraph so it reads something like:
2.3.2 Social meaning
While the formal semantics of an RDF statement (triple) is that of a
distinct assertion, individual RDF statements may have a social meaning
that is partly determined by the circumstances in which they are used.
For example, in English, a statement "I don't believe that 'George is a
clown' is true" contains the statement "George is a clown" and,
considering only that statement, "George is a clown" is a distinct
assertion. However, considering the whole sentence, this wouldn't be
considered an "assertion" (in the socially-understood sense of that
word) that "George is a clown". Similarly, a collection of RDF
statements could be specified in a circumstance in which the social
meaning was that they were not "assertions", but rather falsehoods
(e.g., a collection of RDF statements describing a web page entitled
"famous Internet myths"). At the same time, however, it is important to
understand that RDF/XML documents, i.e. encodings of RDF graphs, *can*
be used to make representations of claims or assertions about the 'real'
world. RDF graphs may be asserted to be true, and such an assertion
should be understood to carry the same social import and
responsibilities as an assertion in any other format (including an
assertion in a natural language document such as a contract). A
combination of social (e.g. legal) and technical machinery (protocols,
file formats, publication frameworks) provide the contexts that fix the
intended meanings of the vocabulary of some piece of RDF, and which
distinguish assertions from other uses (e.g. citations, denials or
illustrations).
On looking again, I also have a problem with the second paragraph, i.e.,
the one that says:
"For example, a media type, application/rdf+xml [RDF-MIME-TYPE ] is
being registered for indicating the use of RDF/XML that might be
published with the intent of being such an assertional representation
(as distinguished from other XML or text that may just happen to look
like RDF assertions)."
The way this whole paragraph follows the first one, it suggests that the
media type will distinguish between uses of RDF that are intended to be
assertions, and uses of RDF that have other meanings "(e.g., citations,
denials, or illustrations)". Then the parenthetical remark at the end
comes along: "(as distinguished from other XML or text that may just
happen to look like RDF assertions)", which suggests that this is a
purely technical issue, to disambiguate RDF from text that might "happen
to look like RDF assertions". I'm not sure this is the same thing.
What I suspect this is saying is that someone might publish RDF
statements in RDF/XML with the intention that these be interpreted as
*other* than assertions (e.g., denials), and that some other media type
will be used to indicate that; the media type application/rdf+xml is
reserved for RDF/XML that is not only RDF/XML, but is intended to
represent "real assertions". I suppose you can use the media type that
way if you want to, but I would argue that characterizing RDF/XML
published with the deliberate intent of representing a bunch of denials
as "other XML or text that just happens to look like RDF assertions" is
highly misleading. If what I suspect you to mean is what you *really*
mean, it would be clearer to state explicitly that the media type is to
distinguish RDF intended to be interpreted as assertions in the social
sense from RDF intended to be interpreted in some other way.
(I know there was some discussion at the telecon about the media type
business, but I missed whether it covered this particular issue or not).
""" ] ;
# -- End of issue --
################ Issue 013 ################
iss:issue
[ iss:name "013-Various" ;
rdfs:label "Review comments posted by TimBL" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Tim Berners-Lee" ;
foaf:initials "TimBL" ] ;
iss:raisedDate "2002-08-18" ;
iss:raisedCite ;
iss:resolvedDate "2002-11-18" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-11-18" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-08-18" ;
iss:cite ;
iss:cite ;
rdfs:comment
"""
Personal comments posted as marked-up copy of document.
These comments cover all aspects of the document. We need to review
more closely to determine what changes are called for.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-09-16" ;
iss:cite ;
rdfs:comment
"""
Additional comment here about assertion.
In particular, the distinguished role of the predicate is noted.
Discuss.
""" ]
[ iss:status iss:Response ;
iss:when "2002-09-30" ;
iss:cite <008-InteractionUnclear.html> ;
rdfs:comment
"""
Other than the comments concerning section 3, most of the points raised have
been worked into the reworking for issue 008-InteractionUnclear.

Specific point addressed separately:
section 2.4.2, denotation of URIs, change made as requested.

Adopting Dan's comment with more emphasis on URIs-in-general than
http: URIs in particular. Also, moved the corresponding text out
of the example sub-section.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-11-08" ;
iss:cite ;
iss:cite ;
rdfs:comment
"""
Issue at least partially reflected in published WD document, and further
in the 2002-11-21 working draft version cited.

I think there's can be big difference in principle between accepting
the truth of a document and accepting a definition given in a document.
In some cases, if a definition depends on the entire content of a document
that contains it, the two may become the same. I'm not ready to go
beyond the first level of acceptance. I don't think RDF needs to say
any more than that at this time, whatever community consensus about
the latter may be.

2a. The difference between formal and natural language is overplayed.

Hmmm... maybe. The meaning is still socially present, but cannot be
formally inferred. All-in-all, we may be better to pull this last
part of section 2.3.3, since I don't think it really adds any new
information to what has gobe before. In it's original form, I think
it was intended as a clarification, but it seems to be more prone
to cause confusion, or disagreement.

2b. Predicate has no special status in determining meaning.

This was my interpretation of a comment made by TimBL. I think
the statement as made is true: for the most part it reinforces the
idea that the meaning of a URI isn't subject to whimsical change.
But the emphasis on the predicate may be overstated.
I could see if I can soften the language there

2c. Only two kinds of entailment.

I think this is more a matter of presentation than of fact.
I think I can see why you find RDF-entailment + "the rest" to
be appealing, but I think that could be a very difficult message
to convey to a wider audience, for whom the very idea of entailment
may be a new concept.

And I think "no way to formally express allowable inferences" is
exactly true of RDF (core). Beyond that, I agree with what you say
about informal description of formal terms, but think that would
be too much to try and say in this document.

---

This is a long commentary, which touches on many subtleties.
Most are beyond the scope of this document to define completely,
because the issues are not fully understood to the extent that there
is a clear community consensus. I find I agree with much of what
is said in sections 4 and 5, to the extent that I understand it, and
don't see that it is greatly at odds with the current text.

Note that I've also added a section 2.4.6 discussing
entailment, which I think touches on some of the points raised.

Finally, I think a point where we diverge is the idea that RDF entailment
is a relationship between documents. I don't think it is. I think
it is a relationship between RDF graphs, which may be contained in
documents or constructed from the contents of one or more documents.
There is some machinery at work here that I think is outside the
scope of the core RDF language specification.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-10-25" ;
iss:cite ;
iss:cite ;
iss:cite ;
iss:cite ;
rdfs:comment
"""
Follow-up from Sandro, and ensuing discussion on RDF-interest.

Concerning:
Re: RDF entailment is a relationship between graphs, not documents. I
don't think the difference matters. I'm happy to rephrase everything
I said to be about graphs. (or I would be if it weren't so long!)

I do think there's a difference, because a graph has a clear formal definition,
but a document does not (in this context).
What this means is that if one provides a formal definition of how to construct
an RDF graph from a document or documents, then the RDFcore definition of entailment
can be applied. Future work may provide such a definition, but to try and do so
now would risk the progress we have made.

Concerning:
Re: "I think [there] can be big difference in principle between
accepting the truth of a document and accepting a definition given in
a document." Yes, in principle, but probably not in fact (alas). See
[2], seconded by Peter.

Well, I think I mis-stated that slightly. RDF itself doesn't do definitions
in this sense: it is interpretations that define denotations of a URIref.
So one won't find any definitions simply by looking at an RDF graph, just
assertions that are true under satisfying interpretations. One might
introduce some convention for a publisher to use RDF to define what they
mean by a URI, but that would be an additional, extra-RDF convention,
and the convention used must distinguish between definitional and other
material. Which puts it out of scope for the current RDF specifications.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-11-29" ;
rdfs:comment
"""
No specific change has been suggested that we think is appropriate
at this time.
""" ]
) ;
iss:sectionRef ;
iss:sectionRef ;
iss:sectionRef ;
rdfs:comment
"""
(This is a very long and complex message.
Please refer to the original message at:
http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0043.html)
""" ] ;
# -- End of issue --
################ Issue 022 ################
iss:issue
[ iss:name "022-SocialMeaning" ;
rdfs:label "Social meaning undermines semantic web" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Peter F. Patel-Schneider" ;
foaf:initials "PFPS" ] ;
iss:raisedDate "2002-10-27" ;
iss:raisedCite ;
iss:resolvedDate "2002-11-29" ;
### Add proper URL when published ###
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-10-29" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-10-27" ;
iss:cite ;
iss:cite <023-SyntaxEquality.html> ;
iss:cite <024-Various.html> ;
rdfs:comment
"""
My precis: see original for detail.

What is the point of material on social meaning?

If not all RDF on the web is assertions, how is this indicated,
or if there is no such way why mention it?

Committing to the meaning of natural language tags: how can
any application do this without natural language understanding?

Committing to the meaning of URI as "ill specified" intent of
some organization, which may be changed at any time. How can
anyone commit to anything involving a URI they don't own?
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-10-28" ;
iss:owner ;
rdfs:comment
"""
GK to field issue.
""" ]
[ iss:status iss:Comment ;
iss:when "2002-11-04" ;
rdfs:comment
"""
The point of this material is that to be useful, RDF has to operate
in a social context. Otherwise it's just an academic exercise.

The mechanism for indicating assertion vs non-assertion is not defined
here. RDF is part of a larger system.

Concerning the need to understand natural language:
I'm having problems understanding the concern here.
I don't recognize the problem raised.
There's no requirement for applications to understand
natural language. I should think about an e-commerce example to
illustrate this.

Committing to intent: I suppose that in a high-value environment, one
would have to be very careful whose URIs you used. Again, I think there
could be an illuminating e-commerce example here.

On commitment: note that it is not an application that makes a
commitment by publishing RDF, but a person or organization who causes
the material to be published.
So committing to a statement that uses someone else's vocabulary
involves an element of trust, like almost any social interaction.
""" ]
[ iss:status iss:Response ;
iss:when "2002-11-29" ;
rdfs:comment
"""
Consider an e-commerce application: a quotation and corresponding purchase
order may be rendered as RDF, thus creating a legal contract.
The quotation contains a human-readable description of goods to be supplied.
In normal operation, an invoice (also rendered as RDF) would create a legal
liability on the customer to make the payment indicated, provided that the
goods described have indeed been supplied. This liability does not depend
on any software's ability to understand the human-readable description of
the goods.

In a plausible implementation, the software systems operated by the customer
would require an additional input in the form of a confirmation from a
suitably authorized person that the goods had been received before responding
to an invoice with a release of payment. Although related, this is a distinct
from the issue of liability addressed in the document.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-11-29" ;
### Add proper URL when published ###
iss:cite ;
rdfs:comment
"""
The text concerned has been revised and simplified for the next WS rekease.
But the fundamental principle remains.
If this continues to be a point of concern then it should be subjected
to wider discussion during last call.
""" ]
) ;
iss:sectionRef ;
iss:sectionRef ;
rdfs:comment
"""
What is the point of the ``social meaning'' stuff? Is it supposed to
indicate that RDF documents available on the web are not always
supposed to be considered to be assertions? If so, how is this done?
Can I, for example, use rdfs:comment to put disclaimers into an RDF
document? If there is no way in RDF to make such disclaimers, then
why bother to bring up the possibility?
I find the whole example about clowns to be completely mystifying. If
you take this example at face value, then *any* use of any RDF commits
to the natural language implications of rdfs:comment tags. How can
any organization deploy an RDF-aware application under these
circumstances (except by having that application understand the
implications of arbitrary natural language).
Similarly, the tying of the meaning of a URI to the ill-specified
intent of some organization poses a giant bar to the deployment of
RDF. Under these circumstances how can any organization use an URI
that they do not own? The owning organization might, after all,
choose to change the meaning of any URI they own at any time. This
seems to me to be a bar to any communication between organizations
using RDF.
""" ] ;
# -- End of issue --
################ Issue 023 ################
iss:issue
[ iss:name "023-SyntaxEquality" ;
rdfs:label "No sense to define equality on literals" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Peter F. Patel-Schneider" ;
foaf:initials "PFPS" ] ;
iss:raisedDate "2002-10-27" ;
iss:raisedCite ;
iss:resolvedDate "2002-11-18" ;
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-11-18" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-10-27" ;
iss:cite ;
iss:cite <022-SocialMeaning.html> ;
iss:cite <024-Various.html> ;
rdfs:comment
"""
What is the point of defining the notion of equality on literals
and other syntax elements?
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-10-28" ;
iss:owner ;
rdfs:comment
"""
Syntax issues assigned to Jeremy.
""" ]
[ iss:status iss:Closed ;
iss:when "2002-11-18" ;
iss:cite ;
iss:cite ;
iss:cite ;
iss:cite ;
iss:cite ;
rdfs:comment
"""
Citation is Jeremy's response on this matter.
The equality definition remains, but with words to point out that this is not
always useful for applications.
""" ]
) ;
iss:sectionRef ;
rdfs:comment
"""
The RDF graph is syntax. As such it makes no sense to define a notion
of equality over literals, which are pieces of syntax. It is just as
if one wanted to defined equality in C by defining it over pieces of a
C program. Similarly, it makes no sense to define equality of nodes
or triples.
""" ] ;
# -- End of issue --
################ Issue 024 ################
iss:issue
[ iss:name "024-Various" ;
rdfs:label "Model theory, examples, inference" ;
iss:raisedBy
[ foaf:mbox ;
foaf:name "Peter F. Patel-Schneider" ;
foaf:initials "PFPS" ] ;
iss:raisedDate "2002-10-27" ;
iss:raisedCite ;
iss:resolvedDate "2002-11-29" ;
### Add proper URL when published ###
iss:resolvedCite ;
iss:owner ;
iss:status iss:Closed ;
iss:when "2002-11-29" ;
iss:history
(
[ iss:status iss:Raised ;
iss:when "2002-10-27" ;
iss:cite ;
iss:cite <022-SocialMeaning.html> ;
iss:cite <023-SyntaxEquality.html> ;
rdfs:comment
"""
No nead to qualify term "Model theory"?

Some examples don't make sense.

RDF does provide some inferential machinery (section 2.2.7?).
""" ]
[ iss:status iss:Assigned ;
iss:when "2002-10-28" ;
iss:owner ;
rdfs:comment
"""
GK working through comments.
""" ]
[ iss:status iss:Response ;
iss:when "2002-11-04" ;
#iss:cite ;
rdfs:comment
"""
Reference to model theory now as used by literature of mathematics and logic.
Given early confusion about RDF, I think this qualification should be made
for non-mathematician readers.