Re: New Draft comments: Multiplicity

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?

R

Received on Monday, 28 January 2013 22:40:23 UTC