seeAlso: last call comments | 2nd last call comments
This is the issue tracking document of RDFCore Working Group.
The www-rdf-comments list is the appropriate method of communicating new issues or concerns to the RDFCore WG.
This document identifies and defines the status of issues considered by the RDFCore Working Group. It is a working document, and as such is subject to constant change as the WG proceeds.
none at this time.
The www-rdf-comments list is the appropriate method of communicating new issues or concerns to the RDFCore WG.
None at this time.
None at this time.
None at this time.
Raised ???, 31 Aug 2000 by Graham Klyne
Summary: The idea of contexts has occurred on several occasions on the mailing lists. Graham Klyne has written a detailed paper on the issue, and there are other uses of the term, e.g. in N3.
Further Discussion:
Currently: postponed (decision, response)
raised Thu, 18 Jan 2001 by Tim Berners-Lee
Summary: The syntax currently allows the expression of the reification of a statement by describing a resource with four properties. A more convenient way of doing this is desirable. Tim is currently using parseType="Quote".
See Also:
Further Discussion:
Currently: Postponed (decision, response)
Raised Wed, 14 Feb 2001 by Graham Klyne
Summary: The RDF XML syntax uses XML qnames to represent property URI's. However, not all possible property URI's, for example, http://acme.com/property/ can be represented in this manner. This is an example of a more general issue, that the RDF XML syntax cannot represent all possible RDF models.
Further Discussion:
Currently: Postponed (decision, response)
raised Wed, 18 Apr 2001 by Graham Klyne
Currently, resource identifier values specified in attributes such as "about", "resource", "aboutEach" and "type" are specified as URI-references. The same resources used in element or attribute names are specified as Qnames. Other specifications permit the use of Qnames in attribute values. It would enhance readability of RDF were also to do so.
Further Discussion:
Currently: Postponed (decision, response)
raised Thu, 14 Jun 2001 by Jan Grant
Summary: A graph which contains an anonymous resource which is the object of two statements cannot be represented in the RDF/XML syntax unless a URI is assigned to the resource.
In a nutshell, there is no way to represent the following (n-triple) model in RDF/XML:
_:a1 <http://random.ioctl.org/#p1> _:a2 .
_:a2 <http://random.ioctl.org/#p2> _:a1 .
See Also: rdfms-qnames-cant-represent-all-uris
On 26th July 2002, the WG decided to re-open this issue and accept the proposal (as amended) to add an rdf:nodeID to the syntax for specifying blank nodes in triple subject and object positions.
Currently: Postponed (decision, response)
raised Mon, 23 Apr 2001 by Lee Jonas
Summary: RDF has an "open grammar, which is harder to validate simply (and nigh on impossible to do properly with DTDs). - Syntax validation within the context of RDF embedded in other XML grammars would be easier if the RDF syntax were only of the 'Fixed-Schema' variety, see [http://lists.w3.org/Archives/Public/www-rdf-interest/2001Apr/0346.html ]. Currently, the propertyElt construct, and abbreviated forms of RDF are of the 'Schema-follows-data' variety.
Resolution: On 9th November 2001, the RDFCore WG resolved
The WG resolves to postpone rdfms-validating-embedded-rdf for later consideration on the grounds that it is out of scope of its current charter to change the current RDF/XML syntax to the extent necessary to address it.
During the last call process of the RDFCore WG further comments (xmlsch-10, xmlsch-12) in a similar vein were received and again the WG decided to postpone. There are strong calls for a new XML syntax for RDF; note Mark Butler's comment on the postponement decision.
Currently: postponed (response)
The RDFCore WG asks the director support the working group's design despite the outstanding dissent on the grounds that:
Raised Wed, Jan 19 2000 by Eric Hellman
Summary: Given web principles, there can in general be no centralised authority which defines the 'correct' URI for any given entity. Should the core RDF specs define a property that specifies two resources to be equivalent?
Resolution: On the 9th November 2001, the RDFCore WG resolved:
Whilst the WG recognises the importance of a mechanism for defining equivalence of URI's, the WG has decided it does not fit within the scope of its current charter. The WG notes that DAML+OIL has an equivalence mechanism which raises the question of which layer of the stack best suits such functionality. The WG also notes that by allowing cycles in rdfs:subPropertyOf and rdfs:subClassOf RDF Schema provides a related mechanism for properties and classes. Consideration of this issue will be postponed.
Currently: postponed (response)
Raised Sun, 18 Aug 2002 by Tim Berners-Lee
Summary: A request that the predicate of a statement may be a b-node to enable expression of the form:
{?x [ :inverse ?p] ?y} => { ?y :p :x }
Currently: postponed
The use of special property names (_1, _2, etc.) can really be quite awkward for expressing ordering. It means that it can be very difficult to add new members to a collection after the event, since the agent doing the adding cannot be sure of knowing what property name to use. This seems to violate the idea of being able to add new RDF statements to any resource at any time.
For non-ordered collections, why not just use 'li' properties? (I suppose one answer would be if multiple instances of a triple are not allowed.)
For ordered collections, why not a linked graph structure -- e.g. a 'Cons' class with 'car' and 'cdr' properties?
It has also been suggested that:
a decent set of collection abstractions should provide for sets
See also:
this has proved a common concern on www-rdf-interest and www-rdf-comments. We need an overview of the various concerns and alternative proposals.
Resolution: On 15th February 2002, the RDFCore WG resolved:
the WG resolves this issue is out of scope for this WG but places the issue on the list of to be considered by a future WG.
Currently: for consideration by a future WG
Raised Sun, 18 Aug 2002 by Tim Berners-Lee
Summary: When RDF is embedded in another document, it is the enclosing document which determines whether the RDF statements are asserted. How should it indicate this to an RDF processor?
Currently: postponed
raised Thu, 08 Mar 2001 by Jim Hendler as a last call comment.
Summary: The parseType="Collection" syntax permits the compact representation of lists of resource, but not of literals.
See Also:
On 11 Mar 2003, the RDFCore WG resolved:
RDFCore resolves to postpone this issue on the grounds that it would require extensive changes to current spec, is not a critical requirement for webont, that it would involve considering several different approaches, taking time and consequent changes to syntax draft, test cases, implementations and primer.
Currently: postponed
raised Thu, 08 Mar 2001 by Dan Connolly
Summary: RDF is not just a data model. The RDF specs should define a semantics so that an RDF statement on the web is interpreted as an assertion of that statement such that its author would be responsible in law as if it had been published in, say, a newspaper.
On 23rd August 2002, the RDFCore WG resolved:
that the text in section 2.3.2 of the Concepts and Abstract Data Model document resolves this issue and it be closed.
However in the light of last call comments, the RDFCore WG resolved:
PROPOSED by GK to strike section 4 from concepts document see: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0029.html
SECONDED by EM
CARRIED with no objection or abstentions.
ACTION 2003-03-11#2, GK: Delete section 4 of concepts document
ACTION 2003-03-11#3, BWM: Move issue rdfms-assertion to postponed
ACTION 2003-03-11#4, EDs: Document editors to review documents for consequential changes
ACTION 2003-03-11#5, EM: Raise issue with SWCG "to prioritize further discussion ..."
ACTION 2003-03-11#7, GK: Respond to (various people) on pfps-14
See Also: The tag issue rdfURIMeaning and the discussion in the semantic web meaning forum.
Currently: postponed
Raised Fri, 28 Feb 2003 as a last call comment by Tex Texin
Summary: A request that there be a mechanism to enable applications to take into account the relationship between different languages when doing language comparisons, i.e. that "en" is, in some sense, a generalisation of "en-US". This issue has been combined with a WG decision to add a postponed issue to define URI's for languages.
Consideration of this issue should also include consideration of standard mechanisms for representing language information about literals as triples in an RDF graph.
Resolution: On 04 Apr 2003, the RDFCore WG resolved to postpone this issue.
Currently: postponed
Raised Fri, 20 Feb 2003 as a last call comment by Ian Horrocks.
Summary: Ian notes that rdfs:comment has semantics, in the sense that a change to an rdfs:comment changes the formal meaning of an ontology. Ian requests a facility for 'real' comments that have no semantics. Rather than change rdfs:comment, Dan Connolly suggested adding a new property.
Resolution: On 11 Apr 2003, the RDFCore WG resolved not to change the semantics of rdfs:comment, and on 02 May 2003 it resolved to postpone this issue.
Raised Fri, 15 Feb 2003 as a last call comment by Jeff Pan .
Summary: Jeff and others (see also qu-03) have requested the defintion of a subset of RDFS that follows a more conventional layered architecture, where for example, rdfs:Class is not a member of itself.
Resolution: On 18 Jul 2003, the RDFCore WG resolved to create a postponed issue to ensure that it is considered by a future WG.
Currently: postponed
Raised Mon, 01 Sep 2003 as a last call comment by Karsten Tolle .
Summary: A request to define a formal semantic relationship between lists and containers.
Currently: postponed
Raised Mon, 10 Nov 2003 Martin Duerst .
Summary: Specifications for languages that embed RDF in them should defer to the RDF specs for the interpretation of fragment identifiers defined in embedded RDF.
Discussion:
Consider say, an SVG document, that contains embedded RDF that defines a fragment identifier. The SVG specification should say that the fragment identifier should be treated as an RDF fragment identifier. It has been suggested that this may be a general issue for the TAG about the treatment of fragment identifiers when one language is embedded in another.
Currently: postponed
Raised Mon, 07 Nov 2003 as a second last call comment by Martin Duerst .
A request that:
_:a eg:prop "foo"^^rdf:XMLLiteral . rdf entails _:a eg.:prop "foo" .
and vice versa.
Resolution: On 07 Nov 2003 the RDFCore WG resolved to postpone this issue with the rationale:
The lack of semantic equivalence between XMLLiterals and plain literals has been clear since the first WD of RDF Concepts, and was arguable in RDF Model and Syntax.
The RDF Semantics does not preclude RDF applications using additional information to determine that two literals are equivalent, but does not mandate that they should be.
Hence, RDF applications which require this equivalence may operate in such a mode, and so this issue is not a show stopper.
Currently: postponed (response)
Raised Mon, 07 Nov 2003 as a second last call comment by Sandro Hawke .
Summary: Sandro observes that the manifest format has an error.
Currently: postponed (response)
Raised Wed, 26 Apr 2000 by Dan Connolly (writeup by Lee Jonas).
Summary: unqualified RDF attributes on element types in the RDF namespace are _not_ equivalent to attributes with the RDF prefix.
see also: Namespaces REC, Namespace Myths article, Problem with the "rdf" namespaces in RDF Model & Syntax
Analysis: According to (the non-normative) Appendix A.2 in the 'Namespaces in XML' spec, attributes with a prefix are in the 'Global Attribute Partition' wheras attributes without a prefix are in the 'Per-Element-Type Partition'. Hence rdf:resource and resource may share a localpart. However they are entirely distinct entities (at least syntactically).
Examples in the RDF spec interchange the qualified and unqualified attributes at different points. Specifically 'rdf:about', 'rdf:type', 'rdf:resource', and 'rdf:value'. The tendancy in the spec is to use unqualified attributes for basic RDF syntax examples and qualified attributes for second and third RDF abbreviated form examples - in these cases the element type is (usually) not in the RDF namespace, so the attribute is given the RDF prefix.
A suggested solution is to use global (qualified) attributes throughout. In order to make the syntax slightly more forgiving, parsers should treat any per-element-type attributes on RDF elements the same as their global counterparts.
Further Discussion:
Resolution:
On 25th May 2001, the WG decided that ALL attributes must be namespace qualified. There is a description of the decision, including detail on the grammar productions affected and a collection of test cases.
Currently: Closed
Raised Tue, 29 Feb 2000 by mailto:timbl@w3.org
Summary: Is it best to put it off to a level of logic above the basic RDF?
See also:
Resolution:
On 1st June 2001, the WG decided
that aboutEachPrefix would be removed from the RDF Model and
Syntax Recommendation on the grounds that there is a lack of implementation
experience, and it therefore should not be in the recommendation. A future
version of RDF may consider support for this feature.
Currently: Closed
raised Fri, 23 Feb 2001 by Karsten-A. Otto
Summary: It is unclear whether an empty property element represents a empty literal or an anonymous resource. Consider the case:
<rdf:Bag> <rdf:li></rdf:li> </rdf:Bag>
The applicable text of section 6 of the Model and Syntax specification states:
3. (same as rule 3 above) If E is an empty element (no content), v is the resource whose resource identifier is given by the resource attribute of E. If the content of E contains no XML markup or if parseType="Literal" is specified in the start tag of E then v is the content of E (a literal). Otherwise, the content of E must be another Description or container and v is the resource named by the(possibly implicit) ID or about of that Description or container.
In this case E is an empty element but there is no resource identifier. Similarly, E contains no XML markup, but has no content.
A similar issue arises in the case:
<rdf:Description> <foo:bar /> </rdf:Description>
Further Discussion:
Resolution.
On 8th June 2001 the WG decided how empty property elements should be interpreted. The decision is fully represented by test cases.
Currently: closed
raised Wed, 09 May 2001 by Dan Brickley
Summary: Parags 189-193 of M+S suggest a privileged role for RDF containers within the formal model at the heart of RDF. Furthermore, they suggest largely unimplemented (**need to hear about Jan's implementation**) constraints, either on XML encodings of RDF, on other (eg. database implementations) or on both. These paragraphs are either in error (RDF does allow for partial descriptions) or editorially redundant.
Resolution: On 8th June 2001 the WG decided that an RDF model may contain partial descriptions of a container. Thus an RDF model is not contrained to have the containermembership properties contiguous starting from rdf:_1. The following therefore, is legal RDF:
<rdf:Bag>
<rdf:_2>2</rdf:_2>
<rdf::_4>4</rdf:_4>
</rdf:Bag>Currently: closed.
Raised Thu, 03 Aug 2000 by Dan Connolly
Summary: The RDF grammar defined in the Model and Syntax Specification is ambiguous. Containers such as rdf:Bag, rdf:Seq and rdf:Alt match the container productions 6.25 through 6.31, but also match the typedNode production (6.13). The container productions attempt to restrict what the language can express about containers, but the ambiguity in the syntax effectively circumvents those restrictions.
See Also:
Resolution:
On 29th June 2001, the WG decided that containers will match the typed node production in the grammar (M&S Section 6, production 6.13) and that the container specific productions (productions 6.25 to 6.31) and any references to them be removed from the grammar. rdf:li elements will be translated to rdf:_nnn elements when they are found matching either a propertyElt (production 6.12) or a a typedNode (production 6.13). The decision includes a set of test cases.
Currently: closed
Raised Wed, Sep 06 2000 by GK@Dial.pipex.com.
Summary: The RDF collection classes (Bag, Seq, Alt) are somewhat irregular in their construction from the XML syntax. Specifically, the RDF parser needs to have special knowledge of these classes in order to recognize that the contained rdf:li properties are really rdf:_1, rdf:_2, etc.
This in turn means that it is not possible to define RDF applications and corresponding schema that declare subclasses of the collection classes for specific purposes, but which can also be treated as any collection class, because a non-schema-aware parser would not know to translate the <li> elements into <_1>, <_2>, etc.
See Also:
Resolution:
On 29th June 2001, the WG decided that containers will match the typed node production in the grammar (M&S Section 6, production 6.13) and that the container specific productions (productions 6.25 to 6.31) and any references to them be removed from the grammar. rdf:li elements will be translated to rdf:_nnn elements when they are found matching either a propertyElt (production 6.12) or a a typedNode (production 6.13). The decision includes a set of test cases.
Currently: closed
Raised Tue, Aug 29 2000 by Stefan Kokkelink
Summary: M&S grammar permits an rdf:aboutEach attribute to be present on a description element which is the object of a statement. How should this be handled?
The RDF grammar permits the following:
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:DC="http://purl.org/metadata/dublin_core/">
<Bag ID="pages">
<li resource="http://foo.org/foo.html" />
<li resource="http://bar.org/bar.html" />
</Bag>
<Description about="URL1">
<DC:Prop>
<Description aboutEach="#pages">
<DC:Creator>Ora Lassila</DC:Creator>
</Description>
</DC:Prop>
</Description>
</RDF>
It is not clear what triples a parser should generate.
Ora Lassila has stated in a response that it was the intention of the working group that rdf:aboutEach attributes should be permitted only on top level description elements.
Resolution: On 29th June 2001, the WG decided that rdf:aboutEach attributes are not allowed on an rdf:Description (or typed node) element which is the object of a statement.
Currently: closed
raised Wed, 24 Jan 2001 by Stefan Decker
Summary: Is a sub-property of rdfs:subPropertyOf necessarily transitive? Ian Horrocks has provided a counter example.
Resolution: The WG decided that a subProperty of rdfs:subPropertyOf need not be transitive based on an explanation provided by Jan Grant.
raised Wed, 14 Jun 2000 by Michel Klein
Summary: The restriction that cycles of subClassOf relationships are prohibited is too restrictive. Cycles of subClassOf relationships are necessary, for example, to represent equivalence between two classes. The submitter contends that cycles of subclass relationships are essential for KR/Ontology languages.
Further Discussion:
Resolution: on 21st Sept 2001, the RDFCore WG resolved:
To resolve issue rdfs-no-cycles-in-subClassOf by deleting the restriction prohibiting cycles of subClassOf properties. The meaning of a cycle of subClassOf properties being an assertion that the classes involved have the same members. A more formal specification of the meaning will be given in the model theory.
Test cases were also approved.
Currently: Closed
Summary: The restriction that cycles of subPropertyOf relationships are prohibited is too restrictive.
Resolution: on 28th Sept 2001, the RDFCore WG resolved:
Deleting the restriction prohibiting cycles of subPropertyOf properties. The meaning of a cycle of subPropertyOf properties is an assertion that the properties involved in the cycle have the same members. A more formal specification of the meaning is given in the model theory.
Test cases were also approved.
Currently: Closed
Raised Sun, Nov 21 1999 by Jonas Liljegren
Summary: The Model and Syntax specification defines the concept of anonymous resources, i.e. resources with no URI represented in the RDF graph or XML serialization. Many parsers automatically generate URI's for such anonymous resources in the triples they produce. Such URI's are often referred to as genid's. Different parsers create different genid's for the same XML input. This raises a number of questions:
If anonymous resources are not labelled with a URI, then it is not possible to represent arbritary graphs with the current RDF XML syntax. For example:
[http://example1]--foo:bar-->[anon-resource]
/\
|
[http://example2]--foo:bar------+
Further Discussion:
Resolution: On 19th October 2001 the WG resolved:
that the RDF model theory draft of 25 September 2001 (http://www.w3.org/TR/2001/WD-rdf-mt-20010925/) adequately addresses the issue http://www.w3.org/2000/03/rdf-tracking/#rdfms-identity-anon-resources
Test cases were also approved.
Currently: Closed (response)
Raised Thu, 20 Jul 2000 by Joe English
Summary: The language in section 6 describing the formal grammar is unclear.
See Also:
Resolution: On 26th October 2001, the WG resolved:
This issue is closed on the grounds that it is resolved by the new approach taken to defining the syntax.
Currently: Closed (response)
raised Thu, 22 Feb 2001 by Dan Connolly
Summary: The grammar in the RDF 1.0 spec is informal and should be replaced. Something based on XML Schema should be considerd.
Further Discussion:
Resolution: On 26th October 2001, the WG resolved:
This issue is closed on the grounds that it is resolved by the new approach taken to defining the syntax.
Currently: Closed (response)
raised Tue 09 Oct 2001 by Dan Connolly
Summary: Are constraint properties and contraint resources useful. If not, the eliminate them.
Resolution: On 9th Novemeber 2001, the WG resolved:
The current mechanism, rdfs:ConstraintResource and rdfs:ConstraintProperty, fails to serve its original purpose and should be removed from the RDF Schema 1.0 specification. The accompanying text be amended accordingly.
Currently: closed (response)
Raised Sat, Nov 1999 by Jonas Liljegren
Summary: RDF describes resources. However, neither the concept of resource, nor how it relates to other concepts such as URI and entity, are precisely defined.
Specific questions that have arisen include:
Topic Maps, as described in the XTM Core Specification distinguishes between the concept of a topic, a similar concept to an RDF resource, and a subject which is the entity the topic represents.
See also:
Further Discussion:
Resolution: On 9th November 2001 the RDFCore WG resolved:
The WG closes rdfms-resource-semantics on the grounds that the model theory says all that RDF is normatively going to say about the nature of resources. Further specification of the nature of resources is the work of other WG's.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Dan Connolly
Summary: The current RDF terminology is inconsistent with the long established terminology used by logicians. For example, what RDF'er's call a 'model' is called an 'abstract syntax' by logicians. Logicians use the term model but for something quite different.
Resolution: On the 9th November 2001, the RDFCore WG resolved:
The WG closes rdfms-logical-terminololgy on the grounds that the new terminology introduced by the model theory adequately addresses this issue.
Currently: closed (response)
raised Wed, 14 Jun 2000 by Michel Klein
Summary: Ontology languages such as OIL permit multiple range restrictions on a property. If they are to be built on top of RDF Schema, they require the same flexibility. There has been further discussion on how multiple range constraints should be interpretted. Conjunctive semantics requires that a property is constrained by the conjunction (and) of its range constraints; disjunctive semantics require that the property is constrained by the disjunction (or) of its range constraints. It has also been suggested that the semantics of domain constraints be revisted, as development experience has shown the current semantics of domain not to be useful for inference. Further, some symmetry between rdfs:domain and rdfs:range would be expected since the domain of a property is the range of its inverse and vice versa.
Further Discussion:
Resolution: On 2nd August 2001, the RDFCore WG resolved:
Multiple domain and range constraints are permissable and will have conjunctive semantics and this issue is now closed.
Currently: closed (response)
raised Thu, 10 Aug 2000 by James Tauber
Summary: The RDF representation of RDF Schema omits the rdfs:domain and rdfs:range constraints for rdfs:domain
Resolution: On 2nd August 2001, the RDFCore WG resolved:
Domain and range constraints on domain will be included in the next version of the schema document and this issue is now closed.
Currently: closed (response)
raised Tues, 6th Jun 2000 by Wolfgang Nejdl
Summary: The submitter suggests that the properties rdfs:subClassOf, rdf:type, rdfs:domain and rdfs:range should not be defined as instances of rdf:Property, but should instead be primitive. It is contended that rdf would then be less self referential and easier to understand. The argument is documented in The RDF Schema Specification Revisited
Resolution: On 2nd August 2001, the RDFCore WG resoloved:
The issue rdfs-primitive-properties is not a problem and will be closed
Currently: closed (response)
raised Wed, 14 Jun 2000 by Michel Klein
Summary: The semantics of the subPropertyOf relationship is not clear with respect to the inheritance of domain and range constraints.
Resolution: on 2nd August 2001, the RDFCore WG resolved:
subProperties inherit conjunctively the domain and range of their superproperties
Currently: closed (response)
raised Tue, 01 Aug 2000 by Lee Jonas
Summary: The submitter is concerned about RDF schema's, once published, not being able to change. The introduction of a rdfs:deprecated property to enable controlled changes to schema is suggested.
Further Discussion:
Resolution: On 2nd August 2001, the RDFCore WG decided:
to close this issue without action since it is a known problem that is very hard to solve and is outside the scope of this WG.
Currently: closed (response)
Raised Wed, Sep 06 2000 by Wolfram Conen.
[Equivalence]: There are four RDF model "flavours" (formal/data model, graph(ical) model, serialization syntax, triple). To what extend (precisely) are these models (not) equivalent? (Problems related to anonymity have been discussed, see also below, details need to be summarized). Could trying to find transformation grammars be a solution (preciseness, determination of equivalence)? Shouldn't this be in a "formal" part of M&S spec?
Currently: this is a broad topic. Investigation into the notion of a 'better syntax' also touches on this problem: we need to be clear on the boundaries between Model and Syntax, particularly in areas such as 'anonymous resources' which have caused developers some confusion.
See also: RDF data model summary
Resolution: On 16th November 2001, the RDFCore WG resolved:
- The WG agrees that:
- the graph model which is the basis for the model theory
- the n-Triples representation of an RDF graph
- the diagrams of graphs used in documents such as the RDF Model and Syntax document
are currently all equivalent
- The WG resolves to maintain that equivalence (this is a statement of intent rather than a certified fact)
- The WG notes that the RDF/XML syntax as currently defined is unable to represent an arbritary RDF graph. In particular, the RDF/XML syntax cannot fully represent a bNode which is the object of more than one statement.
- The WG believes that extending the RDF/XML syntax so that it can respresent all RDF graphs is beyond the scope of its current charter and resolves to postpone consideration of this issue.
- The WG actions the editor of the RDF Syntax WD to include in that document a clear statement of the RDF graph structures that RDF/XML is unable to represent.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Dan Connolly
Summary: There are gotchas in representing the current RDF model in a logical formalism. For example, a statement is defined as triple containing containing at least two, possibly three resources. Resources are not reasonable things to include in a triple.
Resolution: On 9th November 2001, the RDFCore WG resolved:
The WG closes rdfms-logical-formalism on the grounds that the model theory adequately addresses this issue.
Currently: Closed (response)
Raised Wed, 04 Oct 2000 by Pierre-Antoine CHAMPIN
Summary: what is the difference between writing <Description ID="bar"> and <Description about="#bar">? Why is ID needed?
Further Discussion:
Resolution: On 14th December, the RDFCore WG resolved:
The new syntax WD resolves this issue.
Test cases were also approved (though note that test 2 was not approved pending resolution of an internationalization issue)
Currently: for closed (response)
raised Mon, 04 Jun 2001 by Dan Connolly
Summary: An RDF processor would have to process sub-property relationships to correctly process rdf:aboutEach.
For example, consider using a subproperty of rdf:_2 to specify the second member
of a collection:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:ex="http://example/vocab#">
<r:Description r:about="#books"
xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<r:type r:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
<r:_1 r:resource="#book1" />
<ex:member2 r:resource="#book2" />
<r:_3 r:resource="#book3" />
</r:Description>
<rdf:Description rdf:aboutEach="#books">
<dc:rights xmlns:dc="http://purl.org/dc/elements/1.1/">all
mine!</dc:rights>
</rdf:Description>
<rdf:Description rdf:about="http://example/vocab#member2">
<rdfs:subPropertyOf
rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#_2"/>
</rdf:Description>
</rdf:RDF>
What are the members of #books? Is #book2 one of them? I can deduce, from the specification of rdfs:subProperty, that it is. But knowledge of rdfs:subProperty is not required for parsing rdf:aboutEach syntax, is it?
It has also been suggested that aboutEach is difficult to implement for streaming parsers, which have to retain information about containers in case they encounter a statement with a distributive referrent to that container.
Resolution: On 7th December 2001, the RDFCore WG resolved to remove rdf:aboutEach from the RDF specifications.
Currently: closed (response)
Raised Tue, Aug 22 2000 by Stefan Kokkelink
Summary: M&S Spec says that "The Description element itself represents an instance of a Bag resource...". Does this mean that a parser MUST create a Bag of reified statements for every Description Element?
Resolution: On 11th January 2002, the RDFCore WG resolved:
a parser is not required to create bags of reified statements for all rdf:Description elements, only those which are explicitly reified using an rdf:ID on a propertyElt or by an RDF:bagID on the rdf:Description.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Jonathan Borden
Summary: The algorithm for mapping a QName in the RDF XML syntax to a URI is to concatenate the URI of the namespace with the localname part of the QName. In the case of namespaces, such as the XML Schema datatypes namespace, which do not end in a "#" character, then the URI reference generated by this algorithm is not the same as the conventional URI for the concept.
For example, the XML Schema QName xsd:unsignedInt is referenced using http://www.w3.org/2000/10/XMLSchema#unsignedInt, whereas the RDF translation of this QName is http://www.w3.org/2000/10/XMLSchemaunsignedInt.
It is proposed that the algorithm be modified, so that, when the URI of the namespace ends in a letter or an "_" character, then the URI should consist of the URI of the namespace concatenated with a "#" character then concatenated with the localname.
Further Discussion:
Resolution: On 11th January 2002 the RDFCore WG resolved:
The WG resolves to not change the algorithm for mapping qnames to uris and close this issue on the grounds:
1. Such a change would be a major change to the mapping of RDF/XML syntax to the model and would be beyond our charter.
2. It would cause the same RDF/XML to generate a different graph from existing versus revised implementations
3. Existing code may generate wrong (illegal) graphs for some RDF/XML.
Currently: closed (response)
raised Wed 21 Feb 2001 by Brian McBride
Summary: The RDF Model and Syntax specification states in section 6 that an rdf:ID attribute on a propertyElt [6.12] production identifies the reified statement which the propertyElt produces. In the case where the propertyElt is within a Description element with a distrubitive referrent, such as aboutEach or aboutEachPrefix, the propertyElt represents many statements which cannot all share the same ID.
For example, what triples does the following represent:
<rdf:Bag rdf:ID='bag'/> <rdf:li rdf:resource='http://foo/bag1'/> <rdf:li rdf:resource='http://foo/bag2'/> </rdf:Bag> <rdf:Description rdf:aboutEach='#bag'> <foo:bar rdf:ID='stmtId'>...</foo:bar> </rdf:Description>
Resolution: On 15th February 2002, the RDFCore WG resolved:
the WG resolves that this issue be closed on the grounds that with the removal of rdf:aboutEachPrefix and rdf:aboutEach there are no distributive referrants and the issue is mute.
Currently: closed (response)
raised Thu, 21 Dec 2000 by Bill de hOra
Summary: Communication and discussion within the community interested in RDF is hampered by lack of a disciplined terminology. It is suggested that a glossary of terms be developed to aid effective communication. This is a general issue for all RDF specifications.
Further Discussion:
Resolution: On 15th February 2002 the RDFCore WG resolved:
the WG resolves that this issue is addressed by the primer and that this issue be closed.
Currently: closed (response)
Raised Mon, Nov 22 1999 by Ron Daniel
Summary: The RDF Model and Syntax specification does not cover the nature of RDF graphs in its formal model.
See Also:
The issue originally raised is whether an RDF graph should have a URI (rdfms-uri-for-graph). There have also been proposals for algorithms for generating URI's for RDF graphs aka models.
This is an aspect of a broader issue that the RDF Model and Syntax recommentation discusses the concept of an RDF graph but does not define/describe it in the RDF formal model section. The term 'model' is often used as a synonym for an RDF graph.
Further Discussion:
Resolution: On 15th February 2002, the RDFCore WG resolved:
the WG resolve that the model theory is a formal description of the properties of an RDF graph and that this issue be closed.
Currently: closed (response)
raised ???, ?? ??? ???? by ??? ???
Summary: The RDF data model distinguishes between resources and literals. Only resources may be the subject of a statement. The data: URI scheme enables data to be encoded in the URI of a resource. Thus literals could be represented as resources with data URI's. Such resources could be the subject of a statement. Then, for example, if a string literal were represented as a resource with a data: URI, the language of that property value, could be represented as a property of that resource.
See Also:
Resolution: On 15th February 2002, the RDFCore WG resolved:
that the proposed change would be a major change to the RDF specification and is out of scope for this WG.
Currently: closed
Raised Tue, 29 Feb 2000 by mailto:timbl@w3.org,
Summary: "The object being the union of literal types and reference to node is reasonable: the object may be represented as a pair (type, value) for example (or some other syntax or a pointer into a different part of memory or a pointer to a self-typed object or whatever.) ... You could argue (and people have i understand) that the same ought to hold for the subject of course."
Resolution: On the 15th February 2002, at the RDFCore WG telecon, the WG:
Currently: closed (response)
Raised Tue, 29 Feb 2000 by mailto:jan.grant@bristol.ac.uk,
Summary: "an xmlns-qualified name is a pair of (namespace URI, name); there is no composition function implied apart from the trivial 'shove both bits into a pair'. But RDF claims that resources are (or are identified by) URIs only; there seems to be an (implicit? explicit?) composition function that takes the namespace and the name part and produces a URI from them."
A further related question has been raised. Namespaces are used as an abbreviation in the syntax - are they syntactic sugar or part of the model?
Further Discussion:
Resolution: At the 15th February 2002 telecon, the RDFCore WG:
resolves to close this issue on the grounds that changing how resources are named on the web is a web architecture issue and beyond the scope of our charter.
Whereas:
- the RDF 1.0 spec says that property and class names are computed from element and attribute names by concatenating their namespace names with their local names
- it's useful to be able to process RDF with XPath and XSLT, where even though
- concat(namespace-name(qname1), local-name(qname1))
is the same as
concat(namespace-name(qname2), local-name(qname2))
the qnames themselves may not compare equal in XPath expressions.
- lots of implementors have looked for advice on how to serialize RDF, and, in particular, how to compute a namespace name and localname from the name of a property or a class.
- the WG advises RDF schema/namespace/vocabulary designers choose namespace names that end in non-xml-name-characters such as / # ?
- we advise implementors of RDF serializers in order to break a URI into a namespace name and a local name, split it after the last XML non-name character. If the URI ends in a non-name-character throw a "this graph cannot be serialized in RDF 1.0" exception.
Currently: closed (response)
raised Sat, 08 Mar 2001 by Aaron Swartz
No standard vocabulary is defined for representing boolean valued properties. The author of this suggestion proposes the introduction of two new properties, rdf:is and rdf:isNot. To represent the fact that someone likes chocolate, their resource could have the property rdf:is with a value of foo:ChocolateLover.
Resolution: At the 15th February 2002 telecon, the RDFCore WG decided:
The WG notes that since a boolean-valued property can be identified with a class, rdf:type can be used to represent boolean valued properties. Thus:
<foo> <chocolateLover> <true> .
<foo> <rdf:chocolateHater> <true> .can be represented by
<foo> <rdf:type> <ChocolateLover> .
<foo> <rdf:type> <ChocolateHater> .The WG notes that RDF(S) defines no built in mechanism for expressing that ChocolateLover and ChocolateHater are disjoint classes. The WEBONT WG are defining mechanisms for such expressions. The WG resolves to close this issue.
Currently: closed (response)
Raised Fri, Dec 31 1999 by Eric Hellman
Summary: The grammar does not permit the use of an ID attribute to assign a URI to the reification of a statement where the object of the statement is specified by an rdf:resource attribute.
The RDF Model and Syntax recommendation states that the value of an ID attribute on a propertyElt production [6.12], if specified, is the identifier for the resource that represents the reification of the statement. However, the grammar does not permit both an ID attribute and a resource attribute to present in the same production. Thus:
<rdf:Description> <foo:bar rdf:ID="foobar" rdf:resource="http://foobar"/> </rdf:Description>
is not legal. This can instead be written as:
<rdf:Description>
<foo:bar rdf:ID="foobar">
<rdf:Description rdf:resource="http://foobar"/>
</foo:bar>
</rdf:Description>
thus the same effect can be achieved, however the irregularity in the language may cause confusion.
Resolution:
At the RDFCore WG face to face meeting in February 2002, the WG decided:
<rdf:Description> <foo:bar rdf:ID="foo" rdf:resource="bar"/> </rdf:Description>
is legal.
This issue is now closed.
Currently: closed (response)
raised Mon, 12 Feb 2001 by Pierre-Antoine CHAMPIN
Summary: The Model and Syntax specification does not clearly specify which reified statements are put in which bag when nested description elements have bagID's.
For example, which reified statements should appear in which bag for the the following:
<rdf:Description about="a" bagID="bag1">
<some:prop rdf:ID="st1">
<rdf:Description about="b" bagID="bag2">
<some:otherProp rdf:ID="st2">
A literal
</some:otherProp>
</rdf:Description>
</some:prop>
</rdf:Description>
Resolution: The RDFCore WG has decided:
A bagID reifies the property attributes on the same element as the bagid, the type node and statements immediately arising from property elements that are immediate children of the element containing the bagId. In particular a property element whose statement is part of the bag, which has property attributes, those statements are not part of the bag.
Specifically:
<rdf:Description about="a" bagID="bag1">
<some:prop rdf:ID="st1">
<rdf:Description about="b" bagID="bag2">
<some:otherProp rdf:ID="st2">A literal</some:otherProp>
</rdf:Description>
</some:prop>
</rdf:Description>
generates two bags. Bag1 containts st1 only. Bag2 contains st2 only.
Currently: closed (response)
raised Thu, 14 Jun 2001 by Jeremy Carroll
Summary: Clarify the legality of the use of names from the RDF namespace, e.g. can rdf:Bag be used as a property or can rdf:Description be used as a property attribute etc.
Resolution: On 30th November 2001, the RDFCore WG:
- Resolves that the use of rdf:RDF, rdf:ID, rdf:about, rdf:resource, rdf:bagID, rdf:parseType, rdf:aboutEach and rdf:li except as reserved names as specified in the grammar is an error.
- resolves that test case http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-containers-syntax-vs-schema/test005.rdf be obsoleted
- resolves that a copy of that test case be created as an error test
At the February face to face meeting, the WG futher resolved:
The WG reaffirmed its decision not to restrict names in the RDF namespaces which are not syntactic. The WG decided that an RDF processor SHOULD emit a warning when encountering names in the RDF namespace which are not defined, but should otherwise behave normally.
And that specifically:
<rdf:Description>
<rdf:foo>foo</rdf:foo>
</rdf:Description>
is equivalent to:
_:a <rdf:foo> "foo" .
Currently: Closed (response1, response2)
Summary: A list of general editorial comments on the RDF Model and Syntax specification.
Further Discussion:
Resolution: The RDFCore WG resolved:
Given decision d-2002-02-25-8 [the M&S would be replaced], the editorial issues with M&S are now not relevant to the current document set and this issue be closed.
Status: closed
Raised Sat, 17 Feb 2001 by Dan Connolly
Summary: The property rdf:value is used confusingly and inconsistently throughout the M&S and is never defined. Some have suggested it is used for multi-valued properties (some suggest currying is a better way to do this) and others have claimed it is for defining the lexical representation of a resource. It is requested that the Working Group clarify its meaning and usage.
Resolution: This issue was discussed by the RDFCore WG on 11 January 2002 which resolved:
o resolves to not change the name of this property at this time on the grounds:
- insufficient reasons to make this change
- will cause existing uses to be illegal - such as examples in m&s
o resolves to recast this issue as a need to clarify the semantics of rdf:value.
At the February 2002 face to face meeting, the RDFCore WG resolved:
Currently: Closed (response)
or... "what is it that is identified?"
Raised Tue, 29 Feb 2000 by mailto:timbl@w3.org
Summary: "In the RDF (model/syntax) spec a reference to a subtree of an XML document containing RDF is taken to be a reference to the RDF object." (TimBL)
see also: "how to address RDF fragement", rdf-comments query from mailto:ohto@w3.org. The xml-uri archives also hold much discussion on overlapping themes.
Analysis: this detailed summary by Ralph Swick notes that...
The question of what, exactly, a URI fragment designates in the case of an XML document that uses the RDF namespace is indeed an area that is murky in the spec, I have recently realized. Part of your question has, I claim, a single consistent answer and part has several feasible answers.
One particular aspect of the '#' issue is that the semantics of the fragment identifier in URI references is relative to a mime type:
RDF uses URI-references to identify rdf resources. But the meaning of a fragment identifier is defined only in terms of the MIME type of an entity associated with the resource identified by the URI part. How does the RDF square up to this? What is the MIME type according to which the fragment identifier of an RDF resource identifier is interpreted? Does it depend on the RDF resource involved? Graham Klyne www-rdf-interest@w3.org from September 2000: RDF Issue Tracking Wed, 06 Sep 2000 10:04:07 GMT
This problem elaborated on with examples:
'#' is a downright broken bit of web architecture. The '#' fragment/view semantics are defined as being relative to the mime type of the object. Since mime types can be content-negotiated, that's hairy since a single URI plus '#' doesn't mean much without additional assumptions about mime types. For example, http://www.w3.org/Icons/WWW/w3c_main has both GIF and PNG mime-typed variants. So the semantics of http://www.w3.org/Icons/WWW/w3c_main#foo can't be considered outside the context of some HTTP transaction, since the mime type of the resource isn't an instrinsic property of the resource identified. Dan Brickley, www-rdf-interest@w3.org from March 2000: Re: Subclass of Thing/ Sat, 04 Mar 2000 00:24:21 GMT
Further Discussion:
Resolution: The RDFCore WG resolved:
that RDF uses URI's with fragment ID's to identify resources. This issue is now closed.
It also raised an action to draft text for the primer on th euse of fragment id's with appropriate warnings regarding their semantics and asked Dan Connolly to hightlight this issue with the TAG.
Currently: closed(response)
Summary: "This is a mess - it is in the syntax and not in the model. Should have used an RDF vocabulary for language. It should be removed from the syntax."
Raised Tue, 29 Feb 2000 by mailto:timbl@w3.org
See also: issue rdfms-literalsubjects, which raises the problem of ascribing properties and attributes to RDF.
Resolution: The RDFCore WG resolved:
a literal consists of three components:
- A representation of the parseType, which is a single bit
- A language indicator which is a string as defined in XML
- A fully normalized UNICODE string.
The WG subsequently resolved that typed literals would not have a language tag.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Dan Connolly
Summary: A statement with a parseType of 'Literal' has as its object an XML structure, not a simple string. For example, the first character of the literal <foo>bar</foo> is not '<'.
Background:
Resolution: The RDFCore WG resolved 26 Feb 2002:
a literal consists of three components:
(notice of 26 Feb 2002 decision)
Subsequently the RDFCore WG resolved to treat XML Literals as a datatype.
During review of the Jan 2003 last call drafts, the RDFCore WG resolved 9 May 2003 to refine the structure of XML literals:
Language tag is simply dropped from all typed literals including rdf:XMLLiteral
The WG also decided that normalization of the string component was not required.
In preparation for that decision, the WG considered
four different designs, for the result of an
rdf:parseType="Literal":
Members of the WG have argued that:
An important consideration, reflected most in the comments from the Web Ontology WG and Patel-Schneider's concerns, is that unless rdf:XMLLiteral is a normal datatype with no special treatment of language, then OWL Lite and OWL DL do not support it. No version of the OWL Abstract Syntax has permitted literals other than plain literals (with or without language tags) or typed literals (without a language tag). Thus, any solution, other than the last two of the four above, would require substantive changes to OWL DL and OWL Lite.
To summarize:
|
Special untyped literal |
Special typed literal |
Wrapped normal typed literal |
Normal typed literal no wrapping |
|
|---|---|---|---|---|
|
use a generic datatyping mechanism |
No | No | Yes | Yes |
|
XML syntax ... arbitrary choice |
No | No | Yes | Yes |
|
[permit] non-built-in datatype [like] rdf:XMLLiteral. |
No | No | Yes | Yes |
|
[avoid] an RDF-specific solution [to the problem of] XML [...] context |
Yes | Yes | No | Yes |
|
[avoid] smack[ing] of being a hack |
Yes | No | No | Yes |
|
xml:lang [is] inherited |
Yes | Yes | Yes | No |
|
Works with OWL Candidate Rec |
No | No | Yes | Yes |
Raised Wed, Sep 06 by GK@Dial.pipex.com.
Summary:
"There is a question whether or not there can be two different statements with the same subject, object and property. Most people seem to say "no". I have suggested that this should be allowed because it can be expressed in reified RDF statements and that there should be a 1:1 correspondence between what can be expressed in an RDF model and its reification. " www-rdf-interest@w3.org from September 2000: RDF Issue Tracking Wed, 06 Sep 2000 10:04:07 GMT
The RDF Model and Syntax REC says:
This specification shows three representations of the data model; as 3-tuples (triples), as a graph, and in XML. These representations have equivalent meaning. The mapping between the representations used in this specification is not intended to constrain in any way the internal representation used by implementations.
The RDF data model is defined formally as follows:
Resource Description Framework (RDF) Model and Syntax Specification Wed, 24 Feb 1999 14:45:07 GMT
- There is a set called Resources.
- There is a set called Literals.
- There is a subset of Resources called Properties.
- There is a set called Statements,
each element of which is a triple of the form {pred, sub, obj} Where pred is a property (member of Properties), sub is a resource (member of Resources), and obj is either a resource or a literal (member of Literals).
Notes: the set-theoretic language of the Formal RDF model specification has often been cited on www-rdf-interest as evidence that the 'same' statement cannot appear multiple times within a given model.
This is issue is related to the extensive discussion that has occurred concerning the distinction between statings and statements as pointed out by Dan Brickley.
Resolution: The RDFCore WG resolved:
<stmt1> <rdf:type> <rdf:Statement> . <stmt1> <rdf:subject> <subject> . <stmt1> <rdf:predicate> <predicate> . <stmt1> <rdf:object> <object> . <stmt2> <rdf:type> <rdf:Statement> . <stmt2> <rdf:subject> <subject> . <stmt2> <rdf:predicate> <predicate> . <stmt2> <rdf:object> <object> . <stmt1> <property> <foo> .does not entail:
<stmt2> <property> <foo> .
Currently: closed (response)
Raised Fri, 12 Jan 2001 by Peter F. Patel-Schneider
Summary: The lack of a formal semantics for RDF and RDFS make it difficult to construct systems with formal semantics on top of it.
The original message raising this issue lists a number of specific questions:
Resolution: The RDFCore WG resolved:
that the model theory defines formal semantics for RDF and that this issue be closed.
</