- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 21 Sep 2010 17:08:58 +0200
- To: "Young,Jeff (OR)" <jyoung@oclc.org>
- CC: Karen Coyle <kcoyle@kcoyle.net>, public-lld@w3.org
Hi Jeff, If by "human" you mean us geeks who would investigate the data for re-using it, or just for the sake of inspection, I see your point. Otherwise I'm not sure ;-) Antoine > Antoine, > > I would argue that the rdf:type frbr:Expression triple should be > included for human convenience. Good RDF should be intuitive, which is > why OWL and striped RDF are such a nice combination. > > The FRBR model itself may or may not be intuitive, but that's a > different issue. > > Jeff > >> -----Original Message----- >> From: Antoine Isaac [mailto:aisaac@few.vu.nl] >> Sent: Sunday, September 19, 2010 2:32 PM >> To: Young,Jeff (OR) >> Cc: Karen Coyle; public-lld@w3.org >> Subject: Re: Non- and Partial-FRBR Metadata >> >> Jeff, Karen, >> >> As described in http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax- >> parsetype-resource there's another solution, which is tempting: >> >> <frbr:Work rdf:about="http://openlibrary.org/works/OL6037025W/" >> xmlns:frbr="http://purl.org/vocab/frbr/core#" >> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> >> >> <frbr:realization rdf:parseType="Resource"> >> <frbr:embodiment >> rdf:resource="http://openlibrary.org/books/OL18215289M/" /> >> <frbr:embodiment >> rdf:resource="http://openlibrary.org/books/OL6807502M/" /> >> <frbr:embodiment >> rdf:resource="http://openlibrary.org/books/OL7593621M/" /> >> <!-- etc. --> >> </frbr:realization> >> </frbr:Work> >> >> <frbr:Manifestation >> rdf:about="http://openlibrary.org/books/OL18215289M/" >> xmlns:frbr="http://purl.org/vocab/frbr/core#" >> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> >> >> <frbr:embodimentOf rdf:parseType="Resource"> >> <frbr:realizationOf >> rdf:resource="http://openlibrary.org/works/OL6037025W/" /> >> </frbr:embodimentOf> >> </frbr:Manifestation> >> >> This can be interesting, especially if you don't care so much about > the >> type of your blank nodes: if you're using "constrained" versions of >> your FRBR properties, then the data consumers who really care about > the >> types could still be able to infer them from the domain and ranges of >> these properties. The others would avoid manipulating a lot of > rdf:type >> statements... >> >> Cheers, >> >> Antoine >> >> >>> Karen, >>> >>> Here's how an Open Library Work and Manifestation example would look >>> with Expression blank nodes: >>> >>> <frbr:Work rdf:about="http://openlibrary.org/works/OL6037025W/" >>> xmlns:frbr="http://purl.org/vocab/frbr/core#" >>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> >>> >>> <frbr:realization> >>> <frbr:Expression> >>> <frbr:embodiment >>> rdf:resource="http://openlibrary.org/books/OL18215289M/" /> >>> <frbr:embodiment >>> rdf:resource="http://openlibrary.org/books/OL6807502M/" /> >>> <frbr:embodiment >>> rdf:resource="http://openlibrary.org/books/OL7593621M/" /> >>> <!-- etc. --> >>> </frbr:Expression> >>> </frbr:realization> >>> </frbr:Work> >>> >>> Inversely, a Manifestation would look like this: >>> >>> <frbr:Manifestation >>> rdf:about="http://openlibrary.org/books/OL18215289M/" >>> xmlns:frbr="http://purl.org/vocab/frbr/core#" >>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> >>> >>> <frbr:embodimentOf> >>> <frbr:Expression> >>> <frbr:realizationOf >>> rdf:resource="http://openlibrary.org/works/OL6037025W/" /> >>> </frbr:Expression> >>> </frbr:embodimentOf> >>> </frbr:Manifestation> >>> >>> Let me know if you have questions. >>> >>> Jeff >>> >>>> -----Original Message----- >>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net] >>>> Sent: Thursday, September 16, 2010 9:57 AM >>>> To: Young,Jeff (OR) >>>> Cc: Antoine Isaac; public-lld@w3.org >>>> Subject: RE: Non- and Partial-FRBR Metadata >>>> >>>> Can someone give an example of how a blank node will connect a >>>> manifestation to a Work? Is the predicate still "is expression of"? >>>> >>>> kc >>>> >>>> Quoting "Young,Jeff (OR)"<jyoung@oclc.org>: >>>> >>>>> I like Antoine's suggestion. It's lightweight and solves my > concern >>>>> about consistent queries in aggregated RDF data. >>>>> >>>>> I don't like blank nodes as a rule, but this seems like a clear >>>>> exception. >>>>> >>>>> Jeff >>>>> >>>>>> -----Original Message----- >>>>>> From: public-lld-request@w3.org > [mailto:public-lld-request@w3.org] >>>> On >>>>>> Behalf Of Antoine Isaac >>>>>> Sent: Thursday, September 16, 2010 6:46 AM >>>>>> To: public-lld@w3.org >>>>>> Cc: public-lld >>>>>> Subject: Re: Non- and Partial-FRBR Metadata >>>>>> >>>>>> Hi Ross, Jeff, >>>>>> >>>>>> >>>>>>> On Wed, Sep 15, 2010 at 11:28 AM, Young,Jeff >>> (OR)<jyoung@oclc.org> >>>>>> wrote: >>>>>>>> The counter argument is that the dcterms:hasVersion/isVersionOf >>>>>> solution >>>>>>>> isn't documented anywhere and other solutions are plausible. >>>>> Without >>>>>> a >>>>>>>> systematic connection, SPARQL connections between Work and >>>>>> Manifestation >>>>>>>> become a guessing game. >>>>>>>> >>>>>>> You'll notice that in my example I didn't use >>>>>>> dcterms:hasVersion/isVersionOf, but rather rda:workManifested >>>>> (which, >>>>>>> actually, looking more closely at it, doesn't seem right either: >>>> "A >>>>>>> work embodied in a manifestation." with no range -- implying a >>>>>>> literal?). My point actually isn't either of those, it just is >>>>>> making >>>>>>> the point that a direct relationship between M and W is useful, >>>>>> simple >>>>>>> and eliminates a lot of hand waving and teeth gnashing with no >>>>>>> discernible downside. >>>>>>> >>>>>>> And while, no, dcterms:hasVersion/isVersionOf isn't documented >>>>>>> anywhere, if this group saw it as useful (or any other >>> combination >>>>> of >>>>>>> inverse relationships, including something new) it could >>> document, >>>>>>> recommend and endorse it. Then your semantics are there. There >>>> is >>>>>>> practically zero RDF/FRBR/RDA data to draw upon presently - I >>>> don't >>>>>>> see the point in stubbornly sticking to the letter of a model >>> that >>>>> is >>>>>>> currently unproven, unused and doesn't deal well with our >>> hundreds >>>>> of >>>>>>> millions of legacy records. Is the FRBR model so immutable that >>>> it >>>>>>> cannot exist with the addition of a direct relationship between > W >>>>> and >>>>>>> M? If it eases the transition of the old into the new and >>> reduces >>>>>>> costs, wouldn't that generally be considered beneficial? >>>>>>> >>>>>>>> The question is, how much grief will the RDF designer get for >>>>>> wanting to >>>>>>>> coin a new 303 URI? If the framework is flexible, then go ahead >>>> and >>>>>> have >>>>>>>> them coin a 303 URI for Expression: >>>>>>>> >>>>>>>> http://example.org/expression/45678 a frbr:Expression . >>>>>>>> >>>>>>>> My suggestion of using a hash assumes that Expression will >>> always >>>>> be >>>>>> a >>>>>>>> twin to Work and is easily piggybacked on it without fighting >>> for >>>>>>>> infrastructure support. If and when Expressions deserve 303 >>> URIs, >>>>>> the >>>>>>>> old hash URIs can migrate to the 303 URI using owl:sameAs. >>>>>>>> >>>>>>> Unless assertions are applied to the Fauxpression and then you >>> get >>>>>>> into reconciliation, which is expensive and most likely requires >>>>>> human >>>>>>> intervention. >>>>>>> >>>>>>> If the Fauxpression is, indeed, just a placeholder that we > aren't >>>>>>> expecting to add any assertions to -- again, I ask, what's the >>>>> point? >>>>>>> Just to make things more complicated? >>>>>> >>>>>> >>>>>> Btw could we use RDF blank nodes as an alternative here? That >> would >>>>>> bring no extra URI, and *if you think you need it*, the ability > to >>>>> have >>>>>> these FRBR statements that link the W and the M (and thus to >> access >>>>> one >>>>>> from another) . >>>>>> >>>>>> Jeff's solution seems better if one wants to reconcile one day > the >>>> Es. >>>>>> But if we manage to reconcile Ws and Ms properly, I doubt that >>>>>> reconciling *non-described* Es would really bring anything useful >>>>>> addition for an application. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Antoine >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Karen Coyle >>>> kcoyle@kcoyle.net http://kcoyle.net >>>> ph: 1-510-540-7596 >>>> m: 1-510-435-8234 >>>> skype: kcoylenet >>>> >>> >>> >>> >> > > >
Received on Tuesday, 21 September 2010 15:09:40 UTC