Re: New Draft comments: Multiplicity

Hi Rob,


> As always, many thanks for your thorough reading, Antoine!


Happy to see it's helpful :-)

  
>> 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.
>
> If you dereferenced (for example) a Choice, would you expect to get
> back one of the constituent resources, or a description of the Choice
> node in RDF?  The constituent resource would make life easier for
> clients (possibly) but would not be useful for Composite or List.  A
> zip of the resources in a Composite, for example, would not help
> anyone.
>
> I've added:
>      The URI SHOULD NOT be resolvable, but if it is, then an RDF
> description of the construct MUST be returned.


I think the SHOULD is a bit strong, but as I can't really calculate the consequences right now, I'll abstain from objecting.
And yes, if I de-referenced a Choice I'd expect to get the RDF description of the Choice.

>
>
>> 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 thought here was that we should map item to member for clarity,
> but not make oa:List a subclass of rdf:List as there is ongoing
> discussion about how to handle ordering in RDF in the future.  By
> having the two separate gives us a little more flexibility to change
> in the future to follow whatever becomes recommended.
>
> This reasoning doesn't apply to Choice and Composite, but would make
> me (at least) wonder why oa:List wasn't a subclass of rdf:List.  Which
> is what you came to below :)


Indeed!

  
>
>> 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.
>
> True, these should be explicitly rdf:Lists. Will be fixed.


OK.


>
>> 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...
>
> Typically rdf:Lists do not have identifiers, whereas the multiplicity
> constructs are closer to (for example) ore:Aggregations than nameless
> serialization mechanics like blank nodes.  I'll note this in the text.


OK. Be careful with keeping the "typically", though. I suppose there's nothing against giving URIs to rdf:Lists. So this argument is not enough to motivate the


>> 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.
>
> Yes, that's exactly the reason.
>
>> 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.
>
> Producers should.  I'll clarify that in the document.


OK!

>
>> 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.
>> [...]
>
> While a great idea, I'm not sure that we can make assertions like this
> about rdf:first?
>
> My preference, especially at this stage, would be to leave it alone
> and add an editors note that ordering in RDF is inherently problematic
> and future specifications may require changes to the mapping.  This
> would also give an opportunity to explain why we introduce the classes
> rather than just using Alt, Bag and List directly.


I'm ok for the editor note, but then I would use it as an argument for using rdf:List directly. The note can say that this would be reverted if RDF drops or changes lists (which btw I think it won't do: Bag, Seq and Alt are slightly questionable classes, but lists are used in many places, e.g., OWL).

By the way you could treat my suggestion for the axioms "bridging" between rdf:first/rdf:rest and oa:item. Perhaps re-expressing it as an algorithm to obtain oa:item statements from rdf:first/rdf:rest ones. It can be useful to have a (semi-)formal spec in the document. After all, whether it fits OWL(2-DL) or not does not matter much: data producers will have to implement these rules to obtain the desired oa:item statements!

Cheers,

Antoine

Received on Monday, 28 January 2013 21:33:50 UTC