![[Street]-->rdf:_14-->[House]-->dc:description-->"Where I Live"](example1.png)
Present:
| ILRT | Dave Beckett (minutes), Dan Brickley, Phil Cross, Libby Miller, Nikki Rogers (chair) |
| HP Labs | Brian McBride, Stuart Williams |
The RDF Interest Group RDF Issues List and Brian McBride's list were used to find "low hanging fruit" issues that could be usefully discussed in a short meeting. Brian proposed a list of stages for dealing with the issues - describing them, analysing them and discussing / deciding them. He also proposed using a syntax/model split to remove the difficult issues. Dave and Dan disagreed that it wasn't that easy to split them. The group then read the issues and worked out which ones people had an interest in talking about and settled on discussing the container model.
Issues from list:
Issue rdf-containers-syntax-vs-schema: The RDF Model collection classes (Bag, Seq, Alt) require parsers to have
special knowledge of container semantics, making it difficult to subclass these
Issue rdf-containers-otherapproaches: The design of the RDF Model collection classes exhibit various awkward
Dan outlined what he saw as the problems of the container model:
Brian said that the parsers should just deal with parsing and when they see a rdf:li tag, the container rules would always be triggered - start generating rdf:_1 etc. but don't assume that it is a container. Dan said it could be proposed but said don't assume that the rdf:_<n> properties would hang off bags. A discussion was had on the meaning of why resources that are not containers would have an rdf:li element and if that was meaningful or allowed. Dan produced an example that demonstrated such as use, where he used rdf:_14 to mean the 14th house contained in a street:
Dave objected that this was stupid modelling (should use an ordinal from XML schemas) but agreed it was useful to support things like the above to represent partial knowledge, since everything described here is in some context that isn't the whole some total of knowledge.
The issue was reworded in a different way as a proposal: maybe there should be a constraint that the domain of the rdf:li element should always be a container, i.e. a schema thing.
Stuart asked which li element was being discussed and what it meant to have an li element in another namespace. It was generally agreed that it was the rdf:li element that we were discussing. This is related to the issue rdf:resource versus resource attributes, not discussed here.
Dan described that the change to the rdf:li meaning would need an errata for the RDF Model & Syntax (M&S) document - the last paragraph in section 5 which requires that the container elements start at rdf:_1 This forbids things that people might want to do such as have new containers with missing entries, duplicates etc. which have defined semantics, just not those of the containers in M&S.
New Issue: Dan said that containers should be allowed to define the object elsewhere since containers are useful concepts that would be useful to be referred to but currently the syntax forbids this. Mozilla aparently does this, giving containers an about and an URI (using a bug in the RDF syntax).
Brian said then rdf:li rules should always kick in but not assume that the object is a a container (Indeed that is a schema violation). Dan said that it would be useful if rdf:li was a superproperty of rdf:_<n>, but it's not. They are members of rdfs:containerMembershipProperty (henceforce rdfs:cMP) - see outcomes below.
Brian suggested that the various proposals on what to do with rdf:li rules should be described for the RDF-IG list to discuss and vote on.
Stuart asked what were the data merging issues when two containers are merged. Libby said that there is no way to have sequences split across separate files (see also Libby's issue below):
<something about="urn:bla"> <li>Karla</li> <li>Libby</li> <li>Dan</li> </something> <something about="urn:bla"> <li>Dan</li> <li>Ollie</li> </something>
Stuart said this is a list merge with not enough information
Dan said richer stuff comes later - can remake the sequence using data like age, date of publications. Sometimes we have to throw away the ordering constructs and go back to the data.
Nikki said it's a richer stuff problem in seqs etc - tell the developers this. Should we get rid of the spec constraints on more than one rdf:_1, rdf:_2 etc and on starting counting from 1, with no gaps or repetitions?
Dan said that in XML it is at the XML element level that it does the ordering and this means that there may end up being duplicates, which means that restriction is ignored.
Dan said that the constraints on contrainer contents were too strict and should be loosened such that the results ware more amenable to data merging.
New Issue: Libby asked whether the orderings inside the element are relative (to the element) or absolute, in which case data merging is very tricky. There might need to be a defined way to data merge.
Brian asked that this work be derived from (a cleaned up version of) the RDF model, rather than from the syntax point of view. Dan said that rdf:li is only used in the syntax - it has no expression in the model (see above).
Nikki summarised the discussion and the discussion became more focused on producing a list of outcomes and our interpretations of what to do with them (see below).
The M&S "formal container model" expresses constraint rules whose relationship to schema is unclear. In particular the application scope of the constraints is unclear:
Brian said that he would like all constraints expressed in the RDF Schema document
Dan dictated: There is an ambiguity in the formal RDF semantic grammar of the representation of containers using the typed node production since certain specifications of containers can match the typed node production and the built in container syntax. This is problematic in these ways:
10:00 - 15th November 2000, ILRT
Dave Beckett