Developer discussion for Creative Commons technology and tools

[Terry Hancock <hancock AT anansispaceworks.com>]

Mike Linksvayer wrote:
> You replied offlist, in case that was not intentional feel free to
> follow up on or off...

It was a mistake...

> On Mon, 2007-03-26 at 10:46 -0500, Terry Hancock wrote:
> 
>>Mike Linksvayer wrote:
>>
>>>XMP is just a constrained RDF serialization.  DC can be represented as
>>>triples as well, might want to think internally in triples and serialize
>>>them as appropriate for the XMP/native/whatever format.
>>
>>This may be an example of me being "constrained by my tools" in my
>>thinking, but what do "triples" really buy us in this problem domain?
>>I'm working in Python, where a simple map (dictionary) is a natural
>>aggregate datatype (I guess you could call it a "double" :-) ).
> 
> 
> If you have use cases like derivation you're be definition talking about
> multiple works, so you need a way to identify what work you're talking
> about.
> 
> I suppose you implicitly get this with a dictionary per work.
> 
> 
>>In practice, this usually means the "operator" part of triples is
>>implied (I have named fields which map to values -- the mapping is
>>assumed to have the same meaning for the whole dictionary).
>>
>>In the case of DC, the implied operator is basically "is" or "contains",
>>as in "'Creator' contains 'Jane Doe' and 'Joe User'" (which means they
>>are both authors of the work).
> 
> '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".

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

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

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.

Cheers,
Terry

-- 
Terry Hancock (hancock AT AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com