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

Re: New Draft comments: Multiplicity

From: Robert Sanderson <azaroth42@gmail.com>
Date: Mon, 28 Jan 2013 09:42:19 -0700
Message-ID: <CABevsUFfdJm9QFhdiJZpJqAebG83Zuv8qye05GOhOhbXSJbiNQ@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
As always, many thanks for your thorough reading, Antoine!

> 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

I've added:
    The URI SHOULD NOT be resolvable, but if it is, then an RDF
description of the construct MUST be returned.

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

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

Received on Monday, 28 January 2013 16:42:46 UTC

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