New Draft comments: Multiplicity

Hi,

Continuing my comments
http://www.openannotation.org/spec/future/multiplicity.html
as of January 27.

Best,

Antoine

====

1. Resolvability of multiplicity construct resources etc.
The text reads
"Multiplicity Constructs SHOULD have a globally unique URI to identify them, such as a UUID URN."
but remains unclear on whether these URIs should be resolvable. Yet Fig 4.1 presents a non-resolvable Choice resource. This may lead implementers to follow recipes that we don't necessarily want to enforce. Or do we want to have multiplicity nodes always non-resolvable? In which case noting it somewhere would be helpful.


2. Mapping with RDF container classes.
The current model maps oa:item to rdfs:member, which is good.
I was wondering whether we could extend it to RDF Container classes (http://www.w3.org/TR/rdf-schema/#ch_containervocab), the following way:
oa:Choice rdfs:subClassOf rdf:Alt .
oa:Composite rdfs:subClassOf rdf:Bag .

The RDF containers are not extremely useful classes in practice, since they rely more on usage conventions than on sound formal definitions. Hence it makes sense for OA to coin our own classes instead of re-using the RDF ones. Still, the RDF classes are around, and it seems harmless to clarify OA's intended semantics by materializing such mapping.

The case of oa:List and rdf:List is quite important to handle, because the "Model" part in 4.3 mentions them alongside, without stating any sub-class or equivalent-class axiom, which could help readers to understand the relation between them. And rdf:rest's description says that it has lists among possible objects, but doesn't say whether these are oa:List or rdf:List.
The text above the table is a bit more explicit: "the oa:List is at the same time an rdf:List with rdf:first and rdf:rest relationships". But I think OA would benefit from being more explicit.
Given how rdf:List is defined (it hasn't the shortcomings of RDF Containers' definition) and how oa:List is used in the example, I'd suggest making oa:List an equivalent class of rdf:List. Which in turn calls for having just rdf:List in the model. I don't see in the spec something that would argue against this...


3. Use of oa:item with lists
Fig 4.3 introduces the use of oa:item alongside rdf:first and rdf:rest.
I understand that it can be useful for data consumption, enabling direct access a list's members without iteratively querying for all rdf:first and rdf:rest.
But the text doesn't say whether these triples should be introduced by data producers or materialized by data consumers once they get it. And whether they can be automatically infered from the rdf:first and rdf:rest.

As a way to alleviate the issue, and also have better matching between OA and RDF, I'd suggest the following "bridging" axioms:
rdf:first rdfs:subPropertyOf oa:item .
oa:item  owl:propertyChainAxiom  ( rdf:rest  oa:item ) .
It think this would provide a sound basis on which the oa:item statements from Fig 4.3 could be derived.

The downside is that, again, I'm not sure of the "OWL-DL-ness" of this.
I've browsed through the OWL2 specs, but cannot find that OWL considers rdf:first and rdf:rest to be incompatible with such axioms or not. I'm sure that the data would be "DL-ok", because rdf:first and rdf:rest are always used as object properties in RDF graphs. But there could be something in their 'official' definitions (as instances of rdf:Property) that screws things up.

If there are indeed DL-problems that the group judges important to avoid, and if we agree that deriving oa:item automatically from the first/rest patter is interesting, there are two options:
- not declaring the property chain axiom as part of the RDF/OWL ontology, but still pushing it as an official axiom, as is done in some spec (e.g. SKOS)
- "duplicating" rdf:first and rdf:rest in the OA vocabulary itself, defining them as object properties that are sub-properties of rdf:first and rdf:rest. Granted, this would introduce for first and rest the kind of redundancy I don't like for the current oa:List. But this would give us the opportunity to define any axiom we want, while retaining compatibility with applications that consume RDF list constructs. This option is even compatible with a latter decision where we would revert back to recommending to use the rdf:first and rdf:rest. Possible after asking RDF/OWL W3C groups, what we're allowed to do in practice.

Received on Sunday, 27 January 2013 17:10:59 UTC