Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] XMP Developer Challenges and Announcing "Palimpsest"

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: Mike Linksvayer <ml AT creativecommons.org>
  • To: "cc-devel AT lists.ibiblio.org" <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] XMP Developer Challenges and Announcing "Palimpsest"
  • Date: Tue, 27 Mar 2007 21:31:30 -0700

On Tue, 2007-03-27 at 18:34 -0500, Terry Hancock wrote:
> Mike Linksvayer wrote:
> > 'Creator' is the operator and means something like "has this creator".
> > The DC-in-RDF guidelines should make this clear, if nothing else does.
> > Though re-reading the above I suppose you could think of each
> > term/predicate having an implied is/contains/some other relationship
> > implied.
>
> I see -- so in my case, it's actually the "subject" that is implied, not
> the "predicate".

Right.

> >>Supposing I implement an internal representation of RDF triples... what
> >>do I win? :-)
> >>
> >>Or put another way, how many operators are actually sensible in this
> >>context?
> >
> > Operators, if I understand your use above, are never explicit in RDF or
> > DC. The "triple" is subject (e.g., a work), predicate (e.g.,
> > creator/license/source/...), object (e.g., Bob/BY-SA/sourceURI/...)
> >
> >
> >>Not that I'm criticizing the idea -- I just want to understand my choices.
> >
> > Maybe not much, I dictionary per thing being described essentially gets
> > you the same thing.
>
> Yeah, I think so. Certainly I intend for the DC object to apply to
> exactly one work. Realizing the semantics of the RDF/DC concept helps
> me, though. I must say I am bothered by the use of nouns to represent
> "predicates", though -- seems a little linguistically broken. ;-)

Well, you shouldn't really think of "creator" as a part of speech here.
It is loose shorthand for http://purl.org/dc/elements/1.1/creator which
is an opaque identifier with some semantics externally defined.

> In general, ISTM, that you want to have reducing operations on such
> information -- when two people collaborate to make a new work (or one
> person derives a new work from an original), you want to have just one
> licensing and attribution statement for the resulting work.

I'd argue that the most important information is one URL -- where on the
web can I find out more about this work, potentially including lots of
interesting metadata.

> It might be
> nice detail to know who did what exactly, but you also want the
> condensed version that says "this is who you have to credit when you use
> this work". In fact, what you (or I) really want is to have the library
> just flat out tell you the exact wording of the notice you need to use.

I suppose that last sentence points to a human-readable statement in
dc:rights.

> At first it seemed to me that sub-file resources would primarily be only
> of interest to document formats like PDF, but I considered that even
> with seemingly single-work formats like JPG, it's possible to combine
> multiple works into one document (as in the case of an array of pictures
> combined into a single image file). In this case, the ability to refer
> specifically to a particular part of the rendered data is meaningful. So
> it'll need to be a general capability.
>
> So far, though, I'm skirting that issue -- I'm hoping to leave enough
> hooks in place so that it can be added on later.

Sounds like the right approach.

--
http://wiki.creativecommons.org/User:Mike_Linksvayer





Archive powered by MHonArc 2.6.24.

Top of Page