Hi Stuart,

> Pete, I believe that your description of how some see the
> property used and and your comparison with rights is correct.

OK, thanks.

>  However, as comments from others on the UB indicate (see
> Diane's previous post) indicate, that is not the _only_ way
> the property may be used and, in fact, any hint of of that
> specific use was moved from the definition to the comment (as
> best practice) in order to generalize the semantics of the
> property.  So, just as rights may contain a string value made
> up of a rights statement, but can also reference an separate
> rights description, so may the accessibility property.

OK.

> I'd like to hear more regarding your statement: "I think this
> aspect of dc:rights has caused us a few headaches as well,
> and I'm not sure that if we were starting again we'd take the
> same approach."

I think my concern touches on your comment here. dc:rights and the
proposed property (maybe dc:description too) adopt a slightly different
modelling "style" from the other properties. What I mean by that is I
think most of the other properties are deployed to describe a
relationship between the subject resource and another thing

resource-R is-created-by person-P
resource-R has-as-topic concept-C

and so on.

OK, so does dc:rights, and the other thing is a "rights statement". OK,
but suppose I have a description which includes:

resource-R has-rights-statement statement-S

Now, in the case of dc:rights that other thing is, or a least may be, or
may include, a description of, resource-R! i.e. statement S might be an
RDF/XML document containing the statement

resource-R is-available-under-license license-L

So, hang on a minute... why didn't we just say that (using
dcterms:license)? What is the difference between the two approaches?

And why do we say

resource-R has-rights-statement statement-S

rather than

resource-R see-Also statement-S

(using rdfs:seeAlso, which is how you would usually say "more data about
this over here").

As you point out, I think the reason is that we are trying to allow for
both unstructured plain literal "rights statements" and resources as
rights-statements.

I think this really goes back to the more general value-as-resource v
value-as-literal debate. Most RDF vocabularies (I think) don't allow
this choice. Properties which can have literal values are defined to
always have literal values; properties that have other resources as
values don't take literals as values. Now in the Abstract Model, we've
said values are always resources and although we haven't worked out how
this is going to be implemented in RDF, I'm guessing we'll say the
dc:rights RDF property never has a plain literal value, but it could
have some intermediate node with a literal value hanging off it. I'm not
sure that really solves the problem but I haven't thought that bit
through....

I dunno... maybe it's all a non-problem, but the fact that it leads to
some slightly odd questions leaves me with niggling doubts about whether
the underlying approach is quite right. But I appreciate that is a very
vague specification of the problem! ;-)

I was/am really curious to see how the Accessibility people address this
in RDF partly because, well, I just want to know (!), and partly because
I think if they have worked through some of these issues it would
provide some very useful models to guide us. (Andy and I had a brief
chat about this earlier and he commented that similar issues will arise
in the ODRL-DC work that is in progress.) But most of the references I
find are to EARL, and all that material seems to be dated 2001 and I'm
not clear what its status is. And while I think I understand broadly
what EARL does, I'm rather less clear about how it integrates with e.g.
a DC metadata description. From my fairly hasty reading of it, I'm not
really sure I see a need for a dcterms:accessibility property to
reference an EARL statement, just for rdfs:seeAlso to say "there's some
more RDF data over here".

Pete