discussion of the Creative Commons Metadata work

["Shelley Powers" <shelleyp AT burningbird.net>]

> Shelley Powers wrote:
> > I'm not sure why adding the extra structure [in dc:rights and
> > dc:creator] clarifies any confusion. In the example you mention a
> > copyright name holder and a date, but dc:rights can be a name, and
> > dc:date is the date -- is it just the ability to add a URI that
> > enhances the structure?
>
> dc:creator is defined as "An entity primarily responsible for making
> the content  of the resource." not "The name of an entity [...]". It's
> important not to confuse things with their names.
>

Though not as unique as a dummy identifier such as a URI, a name is how most
things are identified. Or more specifically, a name in context and in use.

I wrote Developing ASP Components. Who is the author? Shelley Powers. What
is the author's name? Shelley Powers. In connection with this resource, name
is implied and identifying. My 'name' within the system is 'me'. It's how
I'm represented. We could split semantic hairs, but this system has worked
remarkably well for most business use since we all started to record
metadata on parchment centuries ago.

In relational systems, concatenating the name of the book and my name forms
a unique 'identifier' of me as a person in this context, which is author of
this specific book. Now, to make it easier for the system to work with
authors, it might also have a system generated identifier to act as key, but
it is the 'real' concatenation of values -- book title and author name --
that forms a unique identifier of the person.

I don't think this has ever been a case of confusing names with the actual
thing. I don't think since 'name' has been used as an identifier for
centuries, that anyone has ever confused 'name' with the 'thing'.

Still, neither here nor there.

In Dublin Core, they say "typically the name of a creator should be used to
indicate the entity". True, a more precise definition would have been more
helpful. From a purist perspective, a more complex structure would be more
precise, but wouldn't necessarily be more accurate or more descriptive. By
adding the structure just to identify that the data contained in the element
is a 'name' (or more properly the title of a resource), the data is
structurally not consistent with uses of simple text. And how does one
reconcile the two other than to make a choice.

I used dc:creator before but with simple text, giving the person's name.
This structurally, syntactically, programmatically is not consistent with
dc:creator as it's defined within CC. This is a problem. Is it then that the
CC is going back to DC and Dave Beckett and telling it(him) to modify the
RDF/XML used for DC to match? And all other applications that are now using
dc:creator?

There is already a conflict within weblog postings created using Movable
Type. In MT, dc:creator is the alias used for the author. Within the context
of MT, the alias is a representation of the author. True, it may differ from
my use of dc:creator in PostCon, which is the legal name of the author. But
syntactically, they're the same. And semantically, they're the same because
they are a 'name' used within a specific application that, combined, is used
to identify a unique entity.

'yasd' and weblog.burningbird.net within MT is equivalent to 'Shelley
Powers' and http://burningbird.net/articles/monster1.htm within PostCon.

The fact that we're all using names isn't the problem -- it's that we're
using names within the context of the application, and this can change from
app to app. Adding the extra structure isn't going to fix this because it's
just as easy for me to use 'yasd' as it is to use 'Shelley Powers' -- there
is nothing in the license application that states this must be the person's
legal name. Legally, though, 'yasd and weblog.burningbird.net' and 'shelley
powers and PostCon' are one in the same, and both represent the user. This,
I know, would stand up in a court of law.

There can be a diminishing return to semantic precision.

> A similar argument can be made for dc:rights.
>
> > Second, what kind of mods can we make to the RDF/XML and still not
> > validate
> > the 'license'?
>
> Do you mean invalidate?
>
> > In other words, how much of the license is dependent on the RDF? We
> > can tweak the RDF/XML and still get the same model, but how much of
> > this is dependent. For instance, could I use dc:rights as its used
> > elsewhere?
>
> What do you mean by dependent? The RDF is just a machine-readable
> version of what's in the HTML: "This work is under the X license,
> created by Y, etc."
>

Actually, no. If we annotate the text within the web page -- limiting the
text to only such and such content, as the CC recommended, this annotation
is _not_ picked up in the license within the RDF/XML.

For instance, I attached a CC license to a weblog post. I could identify the
specific post using the permalink, and both the RDF/XML and the HTML are in
synch at this point. However, I said in the text associated with the graphic
of the license that this license only applied to the text of the post, not
any of the photographs embedded in the text. Big difference, and one which
is not conveyed in the RDF/XML.

Now, if people start using only the license to determine if the data within
a RSS feed can be re-published, and the RSS feed contains links to images,
they may assume they can also duplicate the images. But the text in the HTML
specifies not, but may not be included with the RSS feed.

> To bind the license to the work, I think only the cc:license is
> necessary, but I'm not sure whether a court would hold the RDF to be
> legally binding.
>
Denise Howell had looked at some of this and made a convincing argument that
what is legally binding is most likely that which is visible (giving
opinion, not legal advice).

> > Third, are you all going to be adding comments to the schema for
> > something
> > like Brownsauce?
>
> Hm, I haven't played with BrownSauce yet. If you can tell me what the
> necessary comments are, I'd be happy to add them.
>
Kind of thought 'comment' would be enough, but I meant rdfs:comment.

> > The only prohibition so far is commercial use. Can we modify
> > prohibition to
> > add our own?
>
> You can create your own thins with rdf:type cc:Prohibition. Is that
> what you mean?

But this isn't reflected in the formal language of the license, is it? How
are the two reconciled. For instance, I don't want my photos used within
'racist' content. So I might add a prohibition against 'racist use'. Simple
thing to modify the RDF/XML, but what will this do to the validity of the
license?

That's a rhetorical question by the way.

>
> > We can't modify the 'license', because that's static at CC. And
> > I know we can alter the surrounding text for the RDF/XML in the pages,
> > finetune what the data is connected to. But what can we do with the
> > data
> > contained in the RDF/XML without it voiding the license?
>
> You can obviously say more things about the license, but if they are
> inaccurate, it may call the binding of the license into question in
> court, just as you would if you say "this song is public domain but you
> must get my permission before performing for money".

Have forwarded to group.

Thanks for the answers. Enjoy the Segway.

Shelley