W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: New Draft comments: Multiplicity

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Mon, 28 Jan 2013 22:33:22 +0100
Message-ID: <5106EEA2.1050100@few.vu.nl>
To: public-openannotation <public-openannotation@w3.org>
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 :)


>> 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.


>> 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.


>> 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!


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC