# $Id: RDFConceptIssues-group-lcc.n3,v 1.9 2003/07/30 15:26:22 graham Exp $ # # RDF Concepts and Abstract Syntax document # Last call candidate and last call issues list # #--------+---------+---------+---------+---------+---------+---------+---------+ # $Source: /file/cvsweb/ninebynine.org/docs/wip/DocIssues/RDFConceptIssues-group-lcc.n3,v $ # $Author: graham $ # $Date: 2003/07/30 15:26:22 $ # $Id: RDFConceptIssues-group-lcc.n3,v 1.9 2003/07/30 15:26:22 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 - last call 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 <#Editor-GK> foaf:mbox ; foaf:name "Graham Klyne" ; foaf:initials "GK" . <#Editor-JJC> foaf:mbox ; foaf:name "Jeremy Carroll" ; foaf:initials "JJC" . <#Editor-unassigned> foaf:mbox ; foaf:name "Unassigned" ; foaf:initials "?" . # 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 <#Editor-GK> ; iss:editor <#Editor-JJC> ; iss:history # document history ( [ iss:status iss:W3CWorkingDraft ; iss:when "2002-08-29" ; iss:cite ; rdfs:comment """ First official working draft of document. """ ] [ iss:status iss:W3CWorkingDraft ; iss:when "2002-11-08" ; iss:cite ; rdfs:comment """ Second official working draft of document. """ ] [ iss:status iss:W3CGroupLCC ; iss:when "2002-12-13" ; iss:cite ; rdfs:comment """ Working group last call candidate. """ ] [ iss:status iss:W3CGroupLC ; iss:when "2003-01-23" ; iss:cite ; rdfs:comment """ Working group last call 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 101 ################ iss:issue [ iss:name "101-MonotonicLogic" ; rdfs:label "Mention that RDF is monotonic logic" ; iss:raisedBy [ foaf:mbox ; foaf:name "Pat Hayes" ; foaf:initials "PatH" ] ; iss:raisedDate "2002-12-15" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-unassigned> ; iss:status iss:Raised ; iss:when "2002-12-15" ; iss:history ( [ iss:status iss:Raised ; iss:when "2002-12-15" ; iss:cite ; iss:cite ; rdfs:comment """ Request that the concept document contain specific text pointing out that RDF is a monotonic logic. """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ Monotonic logic as a design decision. Couldnt find a suitable reference (!! bummer indeed) so modified this text. It is now broken out as a paragraph: "RDF is an assertional logic, in which each triple expresses a simple proposition. This imposes a fairly strict monotonic discipline on the language, so that it cannot express closed-world assumptions, local default preferences, and several other commonly used non-monotonic constructs. " @@I'd like to make it clear that this particular point isnt just something we didnt get around to, but a positive decision we made. @@I would like us to have this stated explicitly somewhere, and the concepts doc is the obvious place. Hint, hint?? This is actually quite timely, as there is mounting political pressure (mostly from the RuleML folk) to insert highly nonmonotonic extensions into the webont mix, and I'd like us to lock down the point that anything non-mon is not an RDF semantic extension. """ ] ; # -- End of issue 101 -- ################ Issue 102 ################ iss:issue [ iss:name "102-SocialMeaning" ; rdfs:label "Relationship between social meaning and technical mechanisms" ; iss:raisedBy [ foaf:mbox ; foaf:name "Pat Hayes" ; foaf:initials "PatH" ] ; iss:raisedDate "2002-12-16" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-unassigned> ; iss:status iss:Raised ; iss:when "2002-12-16" ; iss:history ( [ iss:status iss:Raised ; iss:when "2002-12-16" ; iss:cite ; iss:cite ; rdfs:comment """ Rethink text dealing with interaction between technical mechanisms and social meaning. """ ] [ iss:status iss:Comment ; iss:when "2002-12-16" ; iss:cite ; rdfs:comment """ Some input from Dan Connolly. """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ NO!! It ought to be about *social* meaning, not *technical* conventions. There is nothing social about the http protocol specification. If it is a technical convention which influences meanings then it ought to be at least mentioned in the MT. You seem to have sneaked some formal semantics in by the back door here, please take it back out again (or make it precise). ... >What I'm trying to capture here is the idea that there are "social >conventions" which are in some way bound to technology deployments. Seems to me that that is exactly what we should NOT be saying. The whole point of this stuff, I always thought, was that the 'social' notions of asserting publicly, referring to, responsibility for lying and being libellous, making promises, etc, etc, are all *just the same* as they always have been, that the technology doesnt *change* any of that, it just provides new ways to do all that old-fashioned stuff. And that RDF is part of that whole process, and should be understood as being; just because it is 'formal' doesn't enable users to wriggle out of their normal social obligations. Now, exactly *how* RDF publication gets treated in this social way is something that is not in our purview, seems to me: we ought not to even be trying to do that, that's like declaring how words shall be used by novelists in the future, or pre-guessing what the Supreme Court is going to decide. So for example maybe things will pan out so that at some future date, a new mime type is established and a dialect of RDF defined to allow 'ironic' RDF which is different in social meaning, but not formal meaning, from current RDF. We do not want to go on record as saying anything that would prevent that happening or require the RDF specs to be re-written if it does. ... I really don't see why we even need to mention URI registration issues at all here. That seems to be someone else's business, unless we want to say that how RDF is interpreted depends in some subtle way on URI registration schemes: in which case, we should say what that way is, as clearly as possible. """ ] ; # -- End of issue 102 -- ################ Issue 103 ################ iss:issue [ iss:name "103-Various" ; rdfs:label "Various concerns, especially with social meaning" ; iss:raisedBy [ foaf:mbox ; foaf:name "Peter F. Patel-Schneider" ; foaf:initials "PFPS" ] ; iss:raisedDate "2002-12-26" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-unassigned> ; iss:status iss:Raised ; iss:when "2002-12-26" ; iss:history ( [ iss:status iss:Raised ; iss:when "2002-12-26" ; iss:cite ; rdfs:comment """ Various points raised. Most fundamentally, concerns with the handling of social (intended) meaning and use of RDF.

Some confusion arounf normative vs non-normative content.

Not clear about XML schema datatypes to be supported.

Some problems of consistency with other documents.

A number of points of terminology, and editorial matters. """ ] [ iss:status iss:Comment ; iss:when "2003-01-17" ; iss:cite ; iss:cite ; iss:cite ; iss:cite ; iss:cite ; rdfs:comment """ See also this thread from the WebOnt discussion list. """ ] [ iss:status iss:FollowUp ; iss:when "2003-02-05" ; iss:cite ; rdfs:comment """ Further comments to RDF-comments. """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ Resource Description Framework (RDF): Concepts and Abstract Syntax Editors' Working Draft 12 December 2002 The notion of what is and what is not normative in this document is very poorly specified. I have been told several times that the definition of an RDF graph in the document is normative, but yet this section is not marked as being normative. I suggest that each section of the document be clearly marked as normative or non-normative. The document contains quite a number of errors and misleading pieces that need to be fixed. It also contradicts itself in a number of places. Abstract I seem to remember learning that ``This document'', etc., are not to be used in an abstract. I only mention this here because the abstract is otherwise so good, being concise and to the point. Its only other flaw is the superfluous paragraph division. After the excellent abstract, however, this document commits the cardinal sin of repeating the abstract at the beginning of the document itself. Section 1: After the excellent abstract, however, this document commits the cardinal sin of repeating the abstract at the beginning of the document itself. If you say the same thing twice, you should at least have the decency to say it in different words. Just what is the RDF core? Is there something else to RDF besides the core? If so, what, and which W3C documents address it? If I was going by the document list, I would be forced to conclude that the semantics for RDFS were in the core, but RDFS itself was not - a very strange state of affairs. RDF datatyping would fall within the core, which is again strange because it depends on RDFS. I would be careful to spell out RDF wherever it is referred to, and avoid short forms such as ``the formalism''. The notion of layering here is also very strange. There is a distinct difference between the relationship between RDF and DC and RDF and OWL. Section 2: This section starts out with a very clear definition of RDF: ``RDF has an abstract syntax that reflects a simple graph-based data model, and formal semantics with a rigorously defined notion of entailment providing a basis for well founded deductions in RDF data.'' If only the RDF documents actually followed this definition of RDF, instead of swerving out to include ``intended meaning'', ``social meaning'', and the like. The list of uses in the motivations section has just about the best example of non-parallel construction that I have ever seen. The list of design goals is, however, a very close second. It wouldn't take much effort to make these lists infinitely more readable. In the list of goals, there is, again, the statement that RDF is supposed to be able to support assertions about anything. This goal runs counter to several efforts to restrict the ability to state assertions about particular resources. The list of goals also has the very strange goal that RDF is supposed to be a basis for legally binding agreements. What part of RDF is going to be able to support this goal? Why not give up on the term ``data model''? It just causes confusion when compared to model theory. Why are literals in RDF if ``URI references are used for naming all kinds of things in RDF''? Inconsistency is a technical term. It would be best not to use it in informal settings, instead talking about false or incorrect statements. As RDF has only a very limited notion of inconsistency, and then only with respect to datatypes, it is misleading to say that applications build upon RDF have to be able to deal with conflicting information. Why not give a quick glimpse of what a simple fact is here instead of using a bare forward reference? Section 3: Are the concepts in Section 3 supposed to be exhaustive in some sense? It almost seems as if they should be, yet there is no indication of whether this is the case. The RDF Primer says that RDF graphs are labeled directed graphs. This document says that the ``underlying structure of any expression in RDF can be viewed as a directed labeled graph''. Neither is correct because RDF graphs are not really labeled directed graphs as they are usually defined, but one would think that at least the same term could be used. Just what is an RDF graph? As this is supposed to be the normative definition of an RDF graph, one would think that an absolutely correct definition would be given here. However, instead one finds that an RDF graph is a set of triples, followed by a diagram that doesn't look like a triple, followed by a quasi-definition of something called a ``property arc'', followed by the claim that an RDF graph contains statements. Something infinitely better is needed here. The next section talks about the nodes and arcs of an RDF graph. However, an RDF graph contains either triples or statements, neither of which are known to have nodes or arcs. This section of the document also talks about the abstract syntax for RDF, which deserves considerable explanation here, but is not even linked to the appropriate section of the document. The datatype section is explicitly tagged as being normative yet it does not specify which XML Schema datatypes are unsuitable for use with RDF, merely mentioning one that is unsuitable. Similarly, the section mentions that XML Schema Datatypes provides an extensibility framework without specifying how such datatypes can be referenced and there are known problems here. (This is particularly frustrating from my view as I just went through this exercise with respect to OWL.) The section on literals makes the claim that anything that can be represented by a literal can be represented by a URI reference. This claim deserves some support, and support based on the RDF model theory. The RDF model theory does not make recommendations. Instead, it states what RDF means in a formal sense. This is not a recommendation, even if one considers W3C standards as recommendations. A two-place predicate is not a simple fact. In fact, it is not a fact at all! A ground atomic term consisting of a two-place predicate and two argument terms might be considered as a simple fact as can be represented in RDF, but not the predicate itself. RDF really only has the power to represent the binary existential-conjunctive fragment of predicate calculus. The existential-conjunctive fragment of first-order logic includes non-binary predicates, which can only be encoded in RDF, and functions, which cannot even be encoded in RDF. The document earlier makes the statement that RDF is supposed to be able to support assertions about anything. It now goes on to contradict that statement, saying that ``[c]ertain URIs are reserved for use by RDF, and may not be used for any purpose not sanctioned the RDF specifications''. These cannot both be true. This section also implicitly makes the claim that RDF Schema is part of the RDF core, contradicting an earlier claim to the contrary. Section 4: What is the ``social meaning'' of RDF? Does it have any relationship to how an RDF application should act? If so, what is this relationship and how can it be conveyed to an application? If not, what business does this have in a document about RDF? How does an RDF expression get to be asserted? What syntax can I use to assert RDF expressions, or to prevent their assertion? Can I use this notion in OWL? If not, then what good is it? Without any method given for asserting an RDF expression or graph, what good is a paragraph that starts ``When an RDF graph is asserted in the Web''? Maybe this section on social meaning has a place in some commentary on the use of RDF, but it certainly doesn't have any place here. The idea that RDF graphs contain ``defining information'' that is opaque to logical reasoners is ludicrous. An RDF graph is simply a set of RDF triples. It is certainly possible that there can be communities that have intended meanings for these RDF graphs, but these intended meanings are external to the RDF graph, and, indeed, external to RDF as a whole, and thus have no place in a normative part of a document about RDF. What social conventions surround the use of RDF? Even if there were some, why should they make their way into a normative section of an RDF document? The idea that some owner of a URI reference can control the use of that URI reference goes counter to the bedrock goal that RDF allows one to say anything about anything. The RDF model theory contains no hint that any of these sorts of restrictions are possible. This section further reinforces this point when it says that any document found by dereferencing a URI reference has no impact on RDF. The example brings forward these problems. The document at http://skunk.example.org/ does not entail anything derogatory about C:JohnSmith, which is reinforced in the section just above. This being the case, there is no reason for any notion related to RDF to bring this forward. If, however, the opposite was the case then there would be no way for any organization to deploy any RDF-based application. Such applications would not be able to understand the social meaning of the RDF they created or manipulated, and thus could easily create documents holding the organization liable for just about any imaginable consequence. In this case I would have no choice but to tell Lucent Technologies not to deploy any RDF applications. Section 6: Just what is an RDF graph? Earlier it was the Graph Data Model and now it is the RDF abstract syntax. I really do expect a much higher level of internal consistency here. The definition of RDF triple is not much better here than before. Two graphs are RDF equal iff they are the same. It would be much better to call the relationship defined here equivalence, or, even better, isomorphism. The treatment of typed literals here does not match that given in the RDF model theory. In particular, there is no provision for the special treatment of rfd:XMLLiteral there. """ ] ; # -- End of issue 103 -- ################ Issue 104 ################ iss:issue [ iss:name "104-ReferenceBroken" ; rdfs:label "Reference [RFC 3066] has broken link" ; iss:raisedBy [ foaf:mbox ; foaf:name "Peter F. Patel-Schneider" ; foaf:initials "PFPS" ] ; iss:raisedDate "2003-01-03" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-unassigned> ; iss:status iss:Raised ; iss:when "2002-01-03" ; iss:history ( [ iss:status iss:Raised ; iss:when "2002-01-03" ; iss:cite ; rdfs:comment """ The hyperlink in reference [RFC3066] is incorrect. """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; iss:sectionRef ; rdfs:comment """ PPS: The pointer to RFC 3066 is wrong in Concepts. It took me a while to discover that I was reading the wrong RFC. """ ] ; # -- End of issue 104 -- ################ Issue 105 ################ iss:issue [ iss:name "105-Various" ; rdfs:label "Various comments" ; iss:raisedBy [ foaf:mbox ; foaf:name "Jan Grant" ; foaf:initials "JanG" ] ; iss:raisedDate "2003-01-06" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-unassigned> ; iss:status iss:Raised ; iss:when "2003-01-06" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-01-06" ; iss:cite ; rdfs:comment """ Various comments; concern about language mentuioning legal issues. """ ] [ iss:status iss:Comment ; iss:when "2003-01-06" ; iss:cite ; iss:cite ; rdfs:comment """ Dan Connolly notes that W3C legal advice is that legal reference is OK. """ ] [ iss:status iss:Comment ; #iss:when "2003-01-06" ; iss:cite <...> ; rdfs:comment """ Dan Connolly notes that W3C legal advice is that legal reference is OK. """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ Section 2.2.3 - The last sentence "The other kind of value..." kind of leaves me hanging, wanting to know what a literal is. And isn't this section about names, not values? Section 3.1 - Is the last sentence a shorthand for "...is the conjunction *of the meaning* of all the statements..."? Actually, that's more confusing, better as it is. Section 3.2 - This chestnut again. Nodes _are_ URIrefs, but arcs are labelled by URIrefs. This is nitpicking though. Section 3.3 - Terms like "paired with exactly one" make the lexical->value mapping sound bijective, although both bullet points taken together make this clear. - XMLLiteral. This might actually be a comment on semantics section 4.1, rule rdf2b. I wasn't sure when I read that if the canonical form of an XML Literal subsumed the lang tag into the literal or whether it's an external thing. If the latter (which section 5 might be seens as giving the lie to) rdf2b needs revision (for a typo). - last paragraph. Note that compound XML schema types are somewhat undersupported at the moment (I think). Section 3.5 - possibly an OWL comment: can OWL express a relational compound primary key using the relational->rdf mapping suggested in this example? Section 3.6 - First paragraph, "The ideas *of* meaning..." Section 4.2, penultimate paragraph. - Be really bloody careful here. Libel law (in the UK at least) does not observe the de re/de dicto distinction; publishing a libellous statement with qualifications or in quotes may constitute libel itself. Don't write anything that might be construed as quasi- legal advice into something published by the W3C (or get someone with a legal head to check it first). Section 4.5 - be careful here too. if the assertion in (B) comes after that in (C), the publishers of (C) might feel hard-done-by should a specification indicate that they are in the wrong (although "previously defined" might be seen as a get-out). Section 6.4 - phew! It's ironic that "universal resource identifiers" have been extended to produce "international resource identifiers". Section 6.5.2 - typo, second paragraph: "the pair *formed* by the lexical form..." Section 7. - first para, I've only ever seen "context-free" hyphenated, although "context dependent" looks fine. Maybe someone can step in with a dictionary? - third bullet point reads to me as with a use/mention problem. I think "Graham Klyne's car" should be in quotes. Is Graham Klyne's car an abstract idea? Or is the notion of his car the idea? In fact, the whole example is borderline Pythonesque. - fourth bullet point reads "Thus: thus, ..." I think that's it. I would add a disclaimer at the top (probably after the penultimate paragraph of section 1) that (particularly non-normative) sections are intended to be illustrative/expositive/explanatory/whatever and not to constitute any form of legal advice. """ ] ; # -- End of issue 105 -- ################ Issue 106 ################ iss:issue [ iss:name "106-Various" ; rdfs:label "Various comments" ; iss:raisedBy [ foaf:mbox ; foaf:name "Patrick Stickler" ; foaf:initials "PatS" ] ; iss:raisedDate "2002-12-30" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-unassigned> ; iss:status iss:Raised ; iss:when "2002-12-30" ; iss:history ( [ iss:status iss:Raised ; iss:when "2002-12-30" ; iss:cite ; rdfs:comment """ Various comments, mostly editorial, some about literals and datatypes """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite <> ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ Here are my comments regarding the Concepts Doc. Issues that I consider critical, to be addressed before actual last call are prefixed with asterisks. Other comments may be considered non-critical, but the editors are certainly welcome to address them before last call, time permitting. 1. Introduction It may be better to say "RDF Base" rather than "RDF Core" in order to (a) sync with the terminology/organization of the XML specs and (b) avoid confusion with "RDF Core WG". 1.1 Structure of this Document The text "RDF's abstract syntax is a graph, which can be serialized using XML (but which is quite distinct from XML's tree-based infoset [XML-INFOSET]). The abstract syntax captures the fundamental structure of RDF, independently of any concrete syntax used for serialization." should probably be moved to just before section 1.1 as it has nothing to do with the structure of the document though is certainly introductory material. 2. Motivations and Goals 2.1 Motivation *** The statement "RDF provides a world-wide lingua franca for these processes." *** is incorrect. RDF is not itself a language for system interaction. It is *** a meta-language for defining languages for system interaction. Just as XML is *** a meta-language for defining document models and is not itself a document model. *** This should be rephrased as something like "RDF provides a common foundation for *** the reliable interchange of information between such processes." 2.2 Design Goals Given the ambiguity of the word "syntax", it might be better if the bullet "XML-based syntax" would rather be "XML-based serialization syntax" (as it is in section 3). 2.2.1 A Simple Data Model 2.2.2 Formal Semantics and Inference 2.2.3 Extensible URI-based Vocabulary 2.2.4 XML-based Syntax 2.2.5 Use XML Schema Datatypes 2.2.6 Anyone Can Make Simple Assertions About Anything 2.2.7 Arbitrary Expression of Simple Facts 2.2.8 A Basis for Binding Agreements 3. RDF Concepts 3.1 Graph Data Model 3.2 URI-based Vocabulary and Node Identification 3.3 Datatypes (Normative) *** No mention is made in this section of datatypes defined in *** frameworks other than XML Schema. It needs to be clearly *** stated that while RDF Datatyping adopts foundational concepts *** from XML Schema Datatyping, and thus XML Schema datatypes are *** (generally) usable with RDF, RDF Datatyping is compatable with *** any datatype conforming to the defined characteristics of *** rdfs:Datatype and need not be defined (or even definable) by *** XML Schema. Since this seems to be the most substantive normative *** definition of RDF Datatyping, this should be made clear here. 3.4 Literals The first sentence "Literals are used to identify values such as numbers and dates by means of a lexical representation." seems only to apply to typed literals, given the language of 'values' and 'lexical representation'. Perhaps a more generic statement is in order, such as "Literals are used to identify resources such as strings, numbers, dates and XML encoded content which in RDF have a non-URIRef textual representation." - Additional clarification of "plain literals ... are self denoting" would be useful, to bring home the fact that the plain literal "25" cannot be interpreted to mean twenty-five. 3.5 Representation of Simple Facts The text "Some simple facts indicate a relationship between two objects. Such a fact may be represented as an RDF triple in which the predicate names the relationship, and the subject and object denote the two objects." is confusing in its use of 'object' with two different senses. Better to use 'resource' for the first sense. E.g. "Some simple facts indicate a relationship between two resources. Such a fact may be represented as an RDF triple in which the predicate names the relationship, and the subject and object denote the two resources." Since everything in RDF is a resource, including literals, this is clearer. - The first real example of the abstract graph syntax seems to be a rather complex one, bringing in relational tables and class typing immediately into the mix. It might be good to first have a more basic example earlier on, without blank nodes, rdf:type, etc. 3.6 Entailment 3.7 RDF Core URI Vocabulary and Namespaces The statement "RDF uses URIs to identify resources and properties." should probably be shortened to just "RDF uses URIs to identify properties." since (a) this section is about vocabulary (properties) and resources may also be identified by literals. 4. Meaning of RDF (Normative) 4.1 Asserted and Non-asserted Forms 4.2 Social Meaning Change "...as an assertion in any other format." to "... as an assertion in any other form." 4.3 Authoritative Definition of Terms 4.4 Interaction Between Social and Formal Meaning 4.5 Example (Informative) 5. XML Content within an RDF Graph (Normative) I am uncomfortable with the convention, but as it seems to work, so be it. Let's see what the community has to say... *** However, it seems odd that we would not be fully compatable *** with XML 1.1 if at all possible. I.e., should we not say that *** all XMLLiteral values should be normalized? 6. Abstract Syntax (Normative) 6.1 RDF Triples 6.2 RDF Graph 6.3 Graph Equality 6.4 RDF URI References 6.5 RDF Literals 6.5.1 Literal Equality 6.5.2 The Value Corresponding to a Typed Literal In the Note:, you could make it clear why it is more useful to compare values rather than lexical forms -- that a given value may have more than one lexical representation and therefore a comparison of forms may return F whereas a comparison of values may return T. 6.6 Blank Nodes 7. Fragment Identifiers 8. Acknowledgments *** Sergey is mentioned in the first paragraph but not the second. I'm *** presuming this was an unintentional omission. 9. References 9.1 Normative References 9.2 Informational References """ ] ; # -- End of issue 106 -- ################ Issue skeleton ################ iss:issue [ iss:name "107-LiteralAsString" ; rdfs:label "Is a plain literal an xsd:string value" ; iss:raisedBy <#Editor-GK> ; iss:raisedDate "2003-01-15" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-GK> ; iss:status iss:Raised ; iss:when "2003-01-15" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-01-15" ; iss:cite ; rdfs:comment """ It's not clear if a plain literal is a member of xsd:string. """ ] [ iss:status iss:Comment ; iss:when "2003-01-16" ; iss:cite ; iss:cite ; iss:cite ; #iss:cite <> ; #iss:cite <> ; rdfs:comment """ Various responses, which more or less seem to agree with the position that language-tagged plain literals are not xsd:string values, and non-tagged plain literals may or may not be.

Note in particular the note from Brian (final citation). I think clarification to the language is needed. """ ] [ iss:status iss:Comment ; iss:when "2003-01-17" ; iss:cite ; rdfs:comment """ Per today's RDFcore telecon, the WG intent is that a plain literal without language tag is a Unicode string, which happens to be the same as the value space of xsd:string. WG have agreed to clarify the intent in the abstract syntax. """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; iss:sectionRef ; iss:sectionRef ; iss:sectionRef ; rdfs:comment """ I'm trying to answer a question that's come up in the CC/PP working group. Can a plain literal be regarded as an instance of xsd:string? I think it's fairly clear that a plain literal with a language tag is not an xsd:string, but less so in the case of a plain literal without a language tag. Here are my test cases: (1) Is the following satisfiable? ex:prop rdfs:range xsd:string . ex:subj ex:prop "abc" . (2) Is the following satisfiable? ex:prop rdfs:range xsd:string . ex:subj ex:prop "abc"@en . My answers are: (1) I'm not sure, but I lean toward "no" on the current wording. The abstract syntax [1] suggests to me that a literal in the abstract graph is a tuple of 1, 2 or 3 elements. (It doesn't say that explicitly, though - it talks of a literal having up to three components.) The formal semantics [2] says that a plain literal denotes itself. [3] and [4] together state that the value space of an xsd:string (being the RDFS class extension of xsd:string treated as an RDF datatype) is a finite sequence of Unicode characters. (I note here that the references are not quite compatible, since XML references [ISO/IEC 10646-2000] and the abstract syntax references [UNICODE], so to be absolutely formally correct we may need to revise the [UNICODE] reference. Do we regard a non-language plain literal as a bare string or a 1-tuple or something else? The language "contains" in [1] suggests it's not a bare string. (2) No (because the two-component value ("abc","en") is not a value in xsd:string -- i.e. is not a finite sequence of characters. In summary, I think the combination of abstract syntax and formal semantics needs tightening up here: either (a) the abstract syntax should be more precise about what it is that contains three components, or (b) the formal semantics should be more explicit about how the components relate to what is denoted by a literal. This may all seem rather arcane, but there's a real issue here: Art Barstow has a proposal for UAProf/CCPP in which xsd:string is used as the range of an property. Could the value of this property possibly be a plain literal? #g -- [1] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Graph-Literal [[ A literal in an RDF graph contains three components called: ]] [2] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/#interp [[ if E is a plain literal then I(E) = E ]] [3] http://www.w3.org/TR/xmlschema-2/#string [[ The value space of string is the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that match the Char production from [XML 1.0 (Second Edition)]. ]] [4] http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-character [[ [Definition: A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646] [E67](see also [ISO/IEC 10646-2000]). Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646. ]] """ ] ; # -- End of issue 107 -- ################ Issue 108 ################ iss:issue [ iss:name "108-CareWithURIDenotations" ; rdfs:label "Merging graphs from disprate sources" ; iss:raisedBy [ foaf:mbox ; foaf:name "Bill de hora" ; foaf:initials "dehora" ] ; iss:raisedDate "2003-01-23" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-GK> ; iss:status iss:Raised ; iss:when "2003-01-23" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-01-23" ; iss:cite ; rdfs:comment """ Bill raises the point that applications or users should be cautious about merging RDF from diufferent sources, in case they are based on different denotations of URIs used.

Maybe this should be worked into a re-working of the sicial meanings section. This is not raised specifically against RDF, but there are thoughts to consider here. """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ Tim Bray wrote: > How about a slight recasting of that: > > 1. Different URIs can identify the same resource, in the opinion of the > creators and users of that resource. > 2. The Web is designed on the principle that a single URI identifies a > single resource which does not change. In practice, this principle is > someties violated (insert list of nasty examples), and software must > often deal with the consequences, but such inconsistency is always > damaging and SHOULD be avoided. -Tim Clearer, thanks. But abuse of this principle also affects specifications such as RDF, as well as web software. For example it will mean we have to merge RDF graphs with great caution before inferences can be made and we have to be careful about RDF queries that span multiple graphs. If the rdf-wg were happy to add words to the primer about how breaking this principle interplays with the function that determines the denotation of a URI, that would help greatly. That is, when merging two RDF graphs, be aware that a URI used in graph 1 might not have the same denotation as it does in graph 2. """ ] ; # -- End of issue 108 -- ################ Issue 109 ################ iss:issue [ iss:name "109-ExpressivePower" ; rdfs:label "What is the expressive power of RDF?" ; iss:raisedBy [ foaf:mbox ; foaf:name "Peter F. Patel-Schneider" ; foaf:initials "PFPS" ] ; iss:raisedDate "2003-01-30" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-GK> ; iss:status iss:Raised ; iss:when "2003-01-30" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-01-30" ; iss:cite ; rdfs:comment """ There is incorrect wording describing the expressive power of RDF. A formal description would be: "The expressive power of RDF is equivalent to the binary existential-conjunctive subset of first order logic". All informal explanations should be consistent with this. """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ RDF Concepts states The expressive power of RDF corresponds to the existential-conjunctive (EC) subset of first order logic [Sowa]. How can takes(John,book,school) be represented in RDF? How can loves(John,spouse(John)) be represented in RDF? How can the RDF and RDFS semantic conditions be represented in the existential-conjunctive subset of first order logic? """ ] ; # -- End of issue 109 -- ################ Issue 110 ################ iss:issue [ iss:name "110-SayAnything" ; rdfs:label "Can RDF say anything about anything?" ; iss:raisedBy [ foaf:mbox ; foaf:name "Peter F. Patel-Schneider" ; foaf:initials "PFPS" ] ; iss:raisedDate "2003-01-30" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-GK> ; iss:status iss:Raised ; iss:when "2003-01-30" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-01-30" ; iss:cite ; rdfs:comment """ There is an apparent contradiction surrounding: "Can RDF say anything about anything"?

The phrase "Say anything about anything" is broken. (I think "Anyone can say something about anything" is closer to the intended goal here.)

However, this phase does not appear in the last-call version of the concepts document.

The document wording should be revised to avoid such misleading suggestions. """ ] [ iss:status iss:FollowUp ; iss:when "2003-01-31" ; iss:cite ; rdfs:comment """ This message offers some examples of the contradiction.

I think the first two examples given are legal, and see no problem with them.

I think the third example is not legal, because it uses a reserved URI inappropriately. But I don't see this illegality as being at odds with the idea that "Anyone can say something about anything".

I think the final example offered is syntactically legal, but unsatisfiable because the RDF specifications don't define any use of rdfs:Class as a property.

So I think the text about what is sanctioned by RDF may require some clarification: some rdf/rdfs URIs are reserved by RDF for specific syntactic purposes, and may not be used to denote resources (e.g. rdf:ID); other rdf/rdfs URIs are reserved to identify specific concepts, for which the corresponding resource is constrained by the RDF specifications, and may not be given an interpretation that is at variance with them. """ ] [ iss:status iss:FollowUp ; iss:when "2003-02-05" ; iss:cite ; iss:cite ; iss:cite ; rdfs:comment """ More clarifying discussion:

I think the position concerning rdf:ID, etc, in RDF/XML is clear from the syntax spec, section 7.1, which excludes 'coreSyntaxTerms' from 'nodeURIs', etc. I acknowledge it is less clear in the Concepts document and that this should be clarified.

Concerning the response to TC2: I think there is a difference between "saying something about anything", and "saying something using any token". The "anything" here is any resource for which a URI can be created. Again, I think the abstract syntax should note that certain URIs are reserved from being used in the subject, predicate or object position.

""" ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; iss:sectionRef ; iss:sectionRef ; rdfs:comment """ Can RDF say anything about anything? The RDF documents are contradictory on this point. The Primer indicates that RDF can be used to let anyone ``say anything they want about existing resources'' with no exception for the resources used by RDF. Concepts says that ``RDF is an open-world framework that allows anyone to make simple assertions about anything''. However, Concepts also says that ``Certain URIs are reserved for use by RDF, and may not be used for any purpose not sanctioned the RDF specifications.'' What is the situation here? """ ] ; # -- End of issue 110 -- ################ Issue 111 ################ iss:issue [ iss:name "111-Various" ; rdfs:label "RDF core, database example, soc-entailment" ; iss:raisedBy [ foaf:mbox ; foaf:name "Ossi Nykanen" ; foaf:initials "OssiN" ] ; iss:raisedDate "2003-01-31" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-GK> ; iss:status iss:Raised ; iss:when "2003-01-31" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-01-31" ; iss:cite ; rdfs:comment """

  1. (1) Suggests a more precise indication of the scope of "RDF core". [Section 1?]
  2. (2) Database example doesn't account of normal database assumption of unambiguous data. [Section 3.5]
  3. (3) Characterization of "social entailment" is too strong. The concern appears to be that agents might somehow be expected to be aware of entailments that are opaque to formal reasoning processes.
I think these are all issues that can be addressed editorially, since I don't think the concerns raised are at odds with the group's intent:
  1. I am happy to include a few words that clarify the scope of RDF core, assuming the WG agree what it is ;-)
  2. I think the database assumption of unambiguity is only a problem if we claim to represent *any* RDF in database form; I don't see any problem there. Can you cite an example of how this ambiguity might be a problem; e.g. some RDF (used as an assertion) that could not be represented in a relational database? I'm happy to clarify this point, but am unsure what particu;ar concern needs to be addressed here.
  3. I agree the issue of social meaning is poorly handled, and needs to be improved. I think the main point we need to convey here is that there may be social meaning associated with some RDF that is opaque to automated reasoning processes. The secondary point is that such meaning may be embodied in some collection of RDF statements, and those statements may be obtained by application of a logically valid reasoning process. The suggestion of non-opacity of social meaning seems to be the issue at the heart of your concerns about it, and I'll try to clarify this.
""" ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; iss:sectionRef ; iss:sectionRef ; rdfs:comment """ I have few remarks concerning the RDF specifications (LCWGs). Outline: #1. RDF-CONSEPTS: The term RDF core is used vaguely (e.g. in sect 1). #2. RDF-CONSEPTS: Example in 3.5 fails to model an actual database? #3. RDF-CONSEPTS: Characterisation on 4.4 about the social meaning of RDF entailments is too strong to be acceptable. [...] Here are the full comments: #1.) In document Resource Description Framework (RDF): Concepts and Abstract Syntax (http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/) the introduction uses the term "RDF core" rather vaguely, e.g. by saying that: "The framework is designed so that vocabularies can be layered on top of a core. The RDF core and RDF vocabulary definition (RDF schema) languages [RDF-VOCABULARY] are the first such vocabularies." ... so RDF core is a vocabulary build on top of a core? Perhaps the intended meaning of the concept "RDF core" (the WG, the fundamental set of RDF specs, or something else?) should be spelled out better since the term "RDF core" will be probably widely used in the discussions about RDF hereafter? #2.) In document Resource Description Framework (RDF): Concepts and Abstract Syntax (http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/), the subsection 3.5. "Representation of Simple Facts" provides an example of encoding a database row as a set of RDF statements. The example is nice but perhaps a bit misleading since databases come with the basic assumption of unambiguous data. If I'm not mistaken, the semantics of the RDF core specifications (RDF Schemas in particular) do not provide a validation mechanism preventing the occurrence of multiple values for the cells when the database is modelled as in the example. For instance, someone might simply write two sentences _:x http://.../city "Bedform" _:x http://.../city "Berlin" which effectively would brake the idea of a database. (For predicates this of course is no problem since they are effectively relations.) #3.) In document Resource Description Framework (RDF): Concepts and Abstract Syntax (http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/), the subsection 4.4. "Interaction Between Social and Formal Meaning" (http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/#section-Interaction) reads: "The meaning of an RDF document includes the social meaning, the formal meaning, and the social meaning of the formal entailments. The assertion of an RDF graph G, when G logically entails G', includes the implicit assertion of G'. The implied assertion of G' should be interpreted using the same social conventions that are reasonably used to interpret the assertion of G." This sounds like a rather strong normative characterisation (perhaps too strong). First, even if I believed that (human or artificial) agents would mutually agree a mechanism for making global vocabulary entailments, I don't think that agents in general are capable (or willing!) of stating only RDF sentences whose entailments they fully agree (or can come feasibly up with and interpret). In addition, by introducing a vocabulary entailment including negation, it's easy to end up with unintentional entailments (effective anything). More reasonable would be saying that agents must either agree on the demonstrated entailments, refine their assertions, or choose a different interpretation theory altogether. Second, in practical situations, there are typically several possibilities for the selection of the RDF graph, only some of which an agent is either capable or willing to consider. For instance, I might only have access to graphs G1, G2, and G3, but willing only to accept the assertions in G1 and G3. Thus if G1 asserts {A->B, E->C}, G3 asserts {C->D}, and even if G2 asserts {B->D}, I would accept only {A->B, E-C, C->D} but not {A->C}. However, there might be a graph G4 (that I, e.g., don't know about) which entails {B->E}, using assertions and inference mechanism that I would accept. From mathematical point of view, the result would be the same (accept G2 or not, by accepting G1, G3, and G4 one would entail A->C), but from the metamathematical point of view, quite different (different proof)--I might argue the same thing as the next guy but with different arguments. In the social context this is extremely important (consider, e.g., the system of law). Thus the entailment path itself should be on focus as well as the result. A trivial example to emphasise this point: G1: {A->C} G2: {A->B, B->C} Socially accepting G1 alone might be harder that its "proof", G2 (which logically does entail G1). (Consider: "JohnSmith is a clown" versus "JohnSmith acts foolishly" and "foolishly acting people are clowns" thus "JohnSmith is a clown".) Perhaps RDF should introduce new concepts, for denoting the particular graph an agent is using (capable and willing) while doing deductions and interpretations, and the notion of a proof (i.e., some assertions are "more valuable" than others since there is a widely accepted proof for them)? [...] """ ] ; # -- End of issue 111 -- ################ Issue 112 ################ iss:issue [ iss:name "112-Namespace" ; rdfs:label "What does RDF consider a namespace to be?" ; iss:raisedBy [ foaf:mbox ; foaf:name "Peter F. Patel-Schneider" ; foaf:initials "PFPS" ] ; iss:raisedDate "2003-01-30" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-GK> ; iss:status iss:Raised ; iss:when "2003-01-30" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-01-30" ; iss:cite ; rdfs:comment """ The question is concerned with whether a namespace is invariant, or can names be added and removed.

This question seems to have no bearing on the definition or interpretation of RDF. Are there any specific problems raised by this issue, or examples of RDF whose interpretation is ill-defined, or specific suggestions for improvement of the text?

I'm not sure that there any change that can usefully be made. """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; rdfs:comment """ What does RDF consider a namespace to be? It appears to me that the XML namespaces document makes XML namespace simply be the set of URI references that share a common prefix. Therefore all XML namespaces contain an infinite and unchanging set of URI references. However, Concepts says that ''Some terms in these namespaces have been deprecated, some have been added, ...'' which appears to indicate that the names in the namespace can be changed. Does RDF actually use a different meaning of a namespace than is used in XML? Other places in the RDF documents also seem to indicate that RDF considers namespaces to have finite and changing sets of URI references. For example, Section 5.1 of RDF Syntax says The [RDF] namespace contains the following names only: ... Any other names are not defined .... Concepts says Vocabulary terms defined in the rdfs: namespace are defined in the RDF schema vocabulary specification .... """ ] ; # -- End of issue 112 -- ################ Issue 113 ################ iss:issue [ iss:name "113-SocialMeaning" ; rdfs:label "Social Meaning and RDF" ; iss:raisedBy [ foaf:mbox ; foaf:name "Peter F. Patel-Schneider" ; foaf:initials "PFPS" ] ; iss:raisedDate "2003-02-05" ; iss:raisedCite ; #iss:resolvedDate "..." ; #iss:resolvedCite ; iss:owner <#Editor-GK> ; iss:status iss:Raised ; iss:when "2003-02-05" ; iss:history ( [ iss:status iss:Raised ; iss:when "2003-02-05" ; iss:cite ; iss:cite ; rdfs:comment """ Does the material on social meaning have any impact on the behaviour of an RDF application? If not, why is the material here at all?

What are the mechanisms by means of which an RDF expression is designated as being asserted, as opposed to an expression which is not regarded as asserting some truth?

Intended meanings are external to the RDF graph, not contained. As such, why are they covered in the normative aspects of RDF specification?

The idea that some party controls the meaning of a given URI is counter to the goal that "anyone can say things about anything". """ ] [ iss:status iss:Comment ; iss:when "2003-02-18" ; #iss:cite ; rdfs:comment """ This comment seems to cover three main areas:

  1. Can RDF be defined as having any social meaning?
  2. If so, does any such meaning affect the behaviour of an RDF application?
  3. How is any such meaning related to the intended interpretation/denotation of URIs?
Of these the first needs further consideration. Is this simply a disagreement about what should and should not be considered normative, or is there a real scenario in which social meaning creates a serious problem? To properly understand the issue raised, and taking account of the answer to the second question (below), please provide an example of a situation where the problems described might materialize.

The answer to the second is a definite "no". The document clearly needs reworking so that it is clear that RDF applications are not expected to be aware of any social meaning associated with the RDF they process.

The third issue also needs further consideration. I cannot understand how the idea that having a designated third party define the intended interpretation of some URI prevents the deployment of any RDF application. Please indicate a scenario in which this might be a real problem. """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; rdfs:comment """ This is a continuation of my comments on what I consider to be a fatal flaw in the RDF specification. I had submitted my views on this flaw to the W3C RDF Core Working Group before the beginning of the Last Call period in the message archived at http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0297.html but the working group chose to go into last call without addressing my comments on this issue. What is the ``social meaning'' (Section 4.2 of RDF Concepts) of RDF? Does it have any relationship to how an RDF application should act? If so, what is this relationship and how can it be conveyed to an application? If not, what business does this have in a document about RDF? How does an RDF expression get to be asserted? What syntax can I use to assert RDF expressions, or to prevent their assertion? Can I use this notion in OWL? If not, then what good is it? Without any method given for asserting an RDF expression or graph, what good is a paragraph that starts ``When an RDF graph is asserted in the Web''? How is social meaning determined? Does it have to be part of the RDF model theory? Does it have to be part of an RDF graph? Does it have to be accessible on the Web? Must it be common knowledge, and for what community? Must it be written down somewhere? Can it exist only in someone's mind? The idea that RDF graphs contain ``defining information'' that is opaque to logical reasoners is ludicrous. An RDF graph is simply a set of RDF triples. It is certainly possible that there can be communities that have intended meanings for these RDF graphs, but these intended meanings are external to the RDF graph, and, indeed, external to RDF as a whole, and thus have no place in a normative part of a document about RDF. What social conventions surround the use of RDF? Even if there were some, why should they make their way into a normative section of an RDF document? The idea that some owner of a URI reference can control the use of that URI reference goes counter to the bedrock goal that RDF allows one to say anything about anything. The RDF model theory contains no hint that any of these sorts of restrictions are possible. The example in Section 4.5 of RDF Concepts brings forward these problems. The document at http://skunk.example.org/ does not entail anything derogatory about C:JohnSmith, which is reinforced in the section just above. This being the case, there is no reason for any notion related to RDF to bring this forward. If, however, the opposite was the case then there would be no way for any organization to deploy any RDF-based application. Such applications would not be able to understand the social meaning of the RDF they created or manipulated, and thus could easily create documents holding the organization liable for just about any imaginable consequence. In this case I would have no choice but to tell Lucent Technologies not to deploy any RDF applications. """ ] ; # -- End of issue 113 -- ################ Issue skeleton ################ iss:issue [ iss:name "nnn-..." ; rdfs:label "..." ; iss:raisedBy [ foaf:mbox ; foaf:name "..." ; foaf:initials "..." ] ; iss:raisedDate "..." ; iss:raisedCite <...> ; #iss:resolvedDate "..." ; #iss:resolvedCite ; #iss:owner <#Editor-GK> ; #iss:status iss:Raised ; #iss:when "..." ; iss:history ( [ iss:status iss:Raised ; iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Comment ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Response ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Resolved ; #iss:when "..." ; iss:cite ; rdfs:comment """ ... """ ] [ iss:status iss:Closed ; #iss:when "2002-??-??" ; iss:cite ; rdfs:comment """ Material incorporated into to publicly accessible document. """ ] ) ; iss:sectionRef ; #iss:sectionRef <> ; #iss:sectionRef <> ; rdfs:comment """ ... text of issue presented """ ] ; # -- End of issue nnn -- iss:theEnd "PlaceHolder" . # # End of last call candidate issue list for RDF Concepts and Abstract Syntax # #--------+---------+---------+---------+---------+---------+---------+---------+ # $Log: RDFConceptIssues-group-lcc.n3,v $ # Revision 1.9 2003/07/30 15:26:22 graham # Sync with CVS # # Revision 1.8 2003/03/04 17:59:12 graham # Sync # # Revision 1.7 2003/02/19 10:01:06 graham # Update issue details # # Revision 1.6 2003/02/18 17:30:41 graham # Add issues 109-111 # # Revision 1.5 2003/02/17 16:06:38 graham # Sync # # Revision 1.4 2003/01/16 15:07:43 graham # Noted LCC review comments from WG # # Revision 1.3 2003/01/14 17:17:04 graham # Add issue 103 # # Revision 1.2 2002/12/17 12:26:30 graham # Add reference to DanC input # # Revision 1.1 2002/12/17 12:14:45 graham # Start last-call-candidate issues list #