- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Tue, 12 Feb 2002 11:36:33 +0000
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: RDF Core <w3c-rdfcore-wg@w3.org>
Some comments. At 03:28 PM 2/11/02 +0000, Brian McBride wrote: >Model and Syntax Issues > >rdfms-not-id-and-resource-attr: The propertyElt production 6.12 of the >grammar does not allow both an ID attribute and a resource attribute to be >specified (owner Dave Beckett) > >Dave has made a proposal in the syntax WD; awaiting counter proposal from >Jeremy. I think Dave proposed making rdf:Id in a property consistently identify a corresponding reification quad. I support that proposal. >rdfms-graph: Formal description of the properties of an RDF graph. > >Basically taken care of by the model theory. Close? I think so. >rdfms-xmllang: Why isn't xml:lang information represented within the RDF >data model? > >This was put on hold whilst we looked at datatypes. Model and Syntax says >that lang is part of the literal; that no triples are generated for an >xml:lang. We can choose to stick with that or change it. Does anyone >have a compelling reason to change it? Having to deal with literals as string, language pairs feels a bit messy to me. If we can treat them cleanly using the datatype mechanisms I'd favour that. I can live with any outcome that clearly indicates how language is encoded in the graph syntax. >rdfms-literals-as-resources: Consider replacing literals with resources >whose URI uses the data: URI scheme. > >I suggest that this would be a significant change to the current spec and >that we just say no on the grounds that it is out of charter. Yes. >rdfms-literal-is-xml-structure : A literal containing XML markup is not a >simple string, but is an XML structure. > >This issue was put on hold pending the outcome of the datatypes >discussion. I suggest we are far enough along on datatypes to bring this >one back. > >rdfms-uri-substructure: xmlns, uri+name pairs or just uris..? >Clarification needed (Sergey Melnik) > >A change from resources being named by URI references, to being named by >pairs, seems like a fundamental change to web architecture. I propose we >rule this out of scope. Seems that way to me. >rdfs-xml-schema-datatypes: A suggestion that the RDF Schema Spec might >usefully use XML Schema datatypes in examples and/or in some formal >specification of the mapping of these datatypes into the RDF model. >(Sergey Melnik) > >ongoing > >rdfms-fragments: Confusing semantics of # fragments > >I propose we remain agnostic on this. Whatever an absolute URI with a >fragmentid names, that is what RDF is describing. I'm not sure this helps out with the "confusing semantics", but I'm not sure what else we can do. I note that a fragment id has no distinguished status in the model theory (unlike web-at-large), so that goes a little way to clear some confusions. >rdfms-literalsubjects: Should the subjects of RDF statements be allowed to >be literals? > >I suggest that changing the RDF/XML syntax to support this is out of >charter. I propose that we resolve this by saying that the current >syntaxes (RDF/XML, n-triples, graph syntax) does not allow literals as >subjects, but this restriction may be removed by a future WG. Assuming it doesn't mess up the model theory, I'd be inclined to not prohibit literals-as-subjects in the graph syntax, but otherwise apply what you say to RDF/XML and N-triples (for now). This would mean that if a future group does define syntax to allow this, there is a semantic foundation ready for it. >rdfms-contexts: Suggestion that the concept of context is missing from RDF. > >I propose that this is out of scope of the current WG. However, if a >bunch of folks wanted to work up a note on the interest lists, that would >be another matter. Yes. >rdfms-identity-of-statements: Does the model allow different statements >with the same subject/predicate/object? > >ongoing Is it? Doesn't the model theory answer this? (I think it's now clear that multiple instances of a statement in a graph don't change the meaning in any way.) >rdf-containers-otherapproaches: The design of the RDF Model collection >classes exhibit various awkward features. Might these be augmented with a >'better' design? > >I propose that this is out of scope for this WG. > >rdf-formal-semantics: The RDF Model and Syntax Rec and RDF Schema CR do >not provide a formal specification of the semantics of RDF. > >taken care of by the model theory Yes. >rdfms-nested-bagIDs: What triples are generated for nested description >elements with bagIDs? > >resolved by syntax WD > >rdfms-replace-value: Suggestion that the rdf:value property be replaced by >rdf:toString. > >Issue modified to clarify the meaning of rdf:value. > >Datatypes is considering using rdf:value in a way that conflicts with >examples in M&S. Data types should use a different property to avoid >clashes with existing usage. rdf:value has no model theoretic meaning; >any interpretation of it is application specific. I'd expect the current datatyping discussion to resolve this. >rdfms-propElt-id-with-dr : Clarify the interpretation of an ID attribute >in the propertyElt production within a Description element with a >distributive referrant. > >Should be closed. As we have removed aboutEach, this issue no longer applies. Yes. >rdfms-seq-representation: The ordinal property representation of >containers does not support recursive processing of containers in >languages such as Prolog. > >Hmmm. Anyone got a proposal for fixing this? I don't think the ordinal property representation is a problem per se, but the lack of a maximum member indicator might be. I can imagine Prolog(ish) something like this: ProcessContainer( C ) :- ProcessContainerFrom( C, 1 ) ProcessContainerFrom( C, N ) :- QueryContainerMember( C, 'rdf:_'+N, S ), ProcessContainerMember( S ), ContainerHasMore( C, N ), ProcessContainerFrom( C, N+1 ). It's not as pretty as list-based processing, but I think it can work if there's a way to evaluate "ContainerHasMore( C, N )". >rdfms-xml-literal-namespaces: How should a parser process namspaces in a >literal which is XML markup? > >This has been on hold pending datatypes outcome. Time to bring back and >resolve. Whatever the outcome, I think it should allow (and be reconcilable with) XML literal values contained in a non-XML serialization of RDF. >rdfms-assertion: RDF is not just a data model; an RDF statement is an >assertion. > >The director has an architectural requirement that we say something about >this. We need someone to draft some appropriate words. Any volunteers? I think the statement should be kept simple. I offered some words a while back: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0560.html [[[ RDF is intended to convey assertions that are meaningful to the extent that they may, in appropriate contexts, be used to express the terms of binding agreements. ]]] >rdfms-boolean-valued-properties: Suggestion for a standard way to >represent boolean valued properties. > >We had decided to model this using rdf:type, but PatH objected to the >wording of the resolution. Awaiting improved wording from PatH. > >rdfms-xml-base: How does xml-base affect RDF?. > >We have decided to allow xml:base anywhere. Awaiting test cases from Jeremy. > >mime-types-for-rdf-docs: What mime type should RDF Schema and other RDF >documents have? > >Aaron has action to register the mime types when we are ready to kick of >the process. > >rdf-terminologicus: The RDF community needs a precise terminology to >enable it to discuss issues.(Martyn Horner) > >We decided the primer should have a glossary. Is that done. Can we close >this? Broadly, yes. (I suggest we close this when there's a public WD of the primer containing the glossary entries, but that's a process issue which I think is a chair's --i.e. your-- call.) >rdf-charmod-literals: Does the treatment of literals conform to charmod ? > >We need an owner to check this. > >rdf-charmod-uris: Does the treatment of uris conform to charmod ? > >We need an owner to check this > >rdfms-rdf-names-use: unusual or illegal use of names from the rdf namespace > >DaveB has action to produce test cases > >rdfms-editorial: General editorial comments. > >No longer apply as we are rewriting the docs Yes. >RDF Schema Issues >· · rdfs-constraining-containers: Should it be possible to >constrain the members of a container to be of a given type? I think that's beyond our scope. WebOnt will allow this, won't it? >· · rdfs-subClassOf-a-Property: Clarify whether a Property can >have a subClassOf property, and if so, what that would mean? I think it would mean the property is also a class. An example would be PatH's datatype classes. >· · rdfs-online-char-encoding: There is problem with the >character encoding of the online RDF Schema. >· · rdfs-clarify-subClass-and-instance: Suggestion of clearer >discussion of use of subClass and instance relationships simultaneously. Schema or primer issue? I think the model theory clarifies the meaning of this, if not the usage. >· · rdfs-isDefinedBy-semantics: Must the value of an >rdfs:isDefinedBy property be a schema? >· · rdfs-editorial: General editorial comments. #g ------------------------------------------------------------ Graham Klyne MIMEsweeper Group Strategic Research <http://www.mimesweeper.com> <Graham.Klyne@MIMEsweeper.com>
Received on Tuesday, 12 February 2002 07:31:35 UTC