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

Re: New Draft comments: Multiplicity

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 29 Jan 2013 17:30:48 +0100
Message-ID: <5107F938.9020807@few.vu.nl>
To: public-openannotation <public-openannotation@w3.org>
On 1/28/13 11:39 PM, Robert Sanderson wrote:
> On Mon, Jan 28, 2013 at 2:33 PM, Antoine Isaac<aisaac@few.vu.nl>  wrote:
>> Hi Rob,
>>> 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.
> I could reduce SHOULD NOT to MAY?    eg The URI MAY be resolvable, ...
> The concern is the same as other identity management issues -- we want
> to allow these nodes to be referred to from other Annotations and
> Linked Data descriptions, but don't want to imply that they should be
> dereferencable.  Especially Choice/Composite/List seem pointless to
> have as resolvable URIs when all you would get is already in the
> Annotation's serialization.

Yes. Btw, just checking: is this (that the description of the construct should be in the one of the annotation) specified in the spec?

>>>> 2. Mapping with RDF container classes.
>>> 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 :)
> Though I should also have noted oa:default as a new predicate for
> Choice that doesn't exist in rdf:Alt.
>>> 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).
> I guess that I'm hesitant to promote Bag and Alt.  If we recommend
> them and they go away, then we're in a mess.
> I think the relationship between the OA and rdf classes is (now)
> clear.  We should (must!) of course reassess this in any future
> Working Group with the RDF 1.1 WG.

Yes, and I think the best way not to forget about it is to note the subclass mapping :-)
Even in the (really unlikely) case that Bag and Alt would be deprecated, it wouldn't hurt OA so much. We're just sub-classing these classes, not re-using them directly.

>> 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!
> Yes... it would reduce the number of mandatory triples, at the expense
> of some additional client side processing.
> I'm not sure that we have a good enough understanding of the field at
> this stage to make a clear determination either way as to which is
> better.

I'd argue that mentioning the axioms is useful even if the data producers are the ones in charge of applying them...

> I think that everyone is happy with an Editor's Note now and
> re-assessing later if/when necessary?

Yes, but I'm in favour of a quite complete Editor's note ;-)\


Received on Tuesday, 29 January 2013 16:31:16 UTC

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