Quoting Ross Singer <[email protected]>:

>
> isn't going to work (frbr:Manifestation being a class, not a
> property).  While you're right that there is no (current) obvious way
> to go jump over frbr:Entities in the WEMI chain, there are some
> options here.


Thanks, Ross.

I think the issue is that there isn't a way to describe the  
manifestation as an object of the Work -- the manifestation needs to  
be expressed as:

URI4Manifestation a type frbr:Manifestation
URI4Manifestation workManifested URI4Work

Without a reciprocal relationship, there isn't a way to say:

URI4Work hasManifestation URI4Manifestation

I was trying to describe the Manifestation with the Work "stripe", but  
that isn't possible (without a new predicate, as Jonathan suggests). I  
hesitate to mess too much  with FRBR -- it's enough of a mess already,  
and following it as best I can is a way (IMO) of showing whether it  
can work or not. (I often think not.)

I'll try another model, then maybe blog it and see what people have to  
say. I also think that it's mainly hard to do this in RDF/XML so maybe  
it's time for me to get adept at turtle.

>
> For the version of the OL data that we host in the Platform, we're
> using dcterms:hasVersion/isVersionOf.

Hmmm. I don't think that meets the definitions of the FRBR group 1  
entities in relation to each other. (I read the FRBR entities as  
additive and hierarchical.) However, in some ways that makes more  
sense to me than the FRBR entity relationships. It would allow you to  
connect any entity to any other entity, not daisy-chaining them the  
way FRBR requires you to. Another option would be to have them all be  
related to a defined whole -- a defined "bibliographic entity." Note,  
however, that the FRBR review group rejects that view (no, I don't  
know what their reasoning is.) That is another possible model that  
would be interesting to play with.

kc


>
> http://api.talis.com/stores/openlibrary/meta?about=http://openlibrary.org/works/OL262758W&output=xml
>
> which isn't great, but the fact that both ends of the chain are
> frbr:Entities, we can infer the meaning.  Even better would be add
> properties to http://open.vocab.org/: something like
> hasManifestation/manifestationOf. Perhaps even better would be to
> leverage http://vocab.org/frbr/core.html#Endeavour - associatedEntity
> as a property name perhaps? - that makes the modeling less
> complicated.  That way we know that these are in the same WEMI chain,
> but we don't necessarily have to explicitly define /what/ it is in the
> relationship.
>
> -Ross.
>
> On Wed, Nov 10, 2010 at 9:28 AM, Karen Coyle <[email protected]> wrote:
>> Quoting Erik Hetzner <[email protected]>:
>>
>>
>>> What I meant to be getting at is that the rdf:type of the resources
>>> M1, M2, ... is (currently) workManifested, while the predicate linking
>>> W and M1, M2, ... is frbr:Manifestation. I think this is backwards;
>>> they rdf:type should be frbr:Manifestation, while the predicate should
>>> be workManifested.
>>
>> Thanks, Erik. From this conversation I have come to the realization
>> that there is no way to say: "this Work is Manifested as..." using
>> FRBR concepts. Instead, what I need to do is to create short "records"
>> for each manifestation that in effect each say: "manifests WorkX". I
>> don't think I can encapsulate the whole in a single rdf/xml unit
>> without creating some uber-structure that holds them together (which
>> would perhaps be a representation of FRBR Group 1 as a super-class,
>> something the the FRBR committee has rejected). I'll mock up something
>> and post it before I code it into the OL template.
>>
>> kc
>>
>>>
>>> As to which direction workManifested points, or its domain or range, I
>>> have no clue, but I assume you are correct here.
>>>
>>> best, Erik
>>> _______________________________________________
>>> Ol-tech mailing list
>>> [email protected]
>>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech
>>> To unsubscribe from this mailing list, send email to
>>> [email protected]
>>>
>>
>>
>>
>> --
>> Karen Coyle
>> [email protected] http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>>
>> _______________________________________________
>> Ol-tech mailing list
>> [email protected]
>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech
>> To unsubscribe from this mailing list, send email to  
>> [email protected]
>>
> _______________________________________________
> Ol-tech mailing list
> [email protected]
> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech
> To unsubscribe from this mailing list, send email to  
> [email protected]
>



-- 
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

_______________________________________________
Ol-tech mailing list
[email protected]
http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech
To unsubscribe from this mailing list, send email to 
[email protected]

Reply via email to