Re: Outstanding Issues

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