Re: New Draft comments: Multiplicity

On Mon, Jan 28, 2013 at 5:39 PM, Robert Sanderson <azaroth42@gmail.com>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.
>
>
> >>> 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.
>
>
> > 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 think that everyone is happy with an Editor's Note now and
> re-assessing later if/when necessary?
>

+1 I see it as a whole future  topic to sort out.