Print

Print


Hi Karen, all,

I'm confused as to when a resource can be both a Work and an Instance at
the same time.  When can a resource be both an abstract concept (Work) and
a class of physical objects (Instance)?

I don't mind if people do inferencing in the privacy of their consuming
application, but I definitely don't want to require it for every
application -- be as simple as possible and no simpler.  The simple method
here, IMO, is to be explicit about the class of the resource.

Rob


On Wed, Nov 5, 2014 at 11:56 AM, Karen Coyle <[log in to unmask]> wrote:

>
> On 11/4/14 5:01 PM, Robert Sanderson wrote:
>  >>
>  Surely the subject's class is determined by a statement with the
> predicate "rdf:type"?
> >
>  You can *infer* a class based on the range or domain of predicates, but
> that doesn't somehow trump an absolute assertion ... which all of the
> examples have, and should be mandatory in any reasonable implementation.
>
>  It's actually easier to *not* do it this way, as you can generate
> unintended inferences.  If you mistakenly attached instanceTitle to a Work,
> that's not an error, it just implies to a reasoner that the Work is also an
> Instance. Much easier to just consistently use bf:title that has no such
> inferences.
> >>
>  [snip much]
>
>   If BIBFRAME is not assuming that the work title and the instance title
>> are key "definers" of the entity, then that is fine.
>
> >
>  >BibFrame should not do this if it is, and therefore it is (or should
> be) fine. :)
>
> Well, this is where we disagree. But perhaps we just have different use
> cases. It sounds like you are warning BIBFRAME not to do inferencing, but
> in the open world, inferencing cannot be prevented. If you want to prevent
> inferencing on Works and Instances then you need to eliminate those as
> classes for all properties. If you want to prevent any combination of Work
> and Instance graphs, then you have to get into some strict disjointness,
> but which only applies when inferencing occurs. Pretty ugly stuff.
>
> In addition, I actually do want to be able to create a "thing" that is
> both a bf:Work and a bf:Instance -- why? Well, why not? If I'm working with
> bibliographic data created in DCterms or something simple like schema.org,
> I see no reason why I cannot express that, for purposes of sharing, as:
>
> :myThing
>   bf:instanceTitle [blah] ;
>   bf:creator [blah] ;
>   bf:subject [blah] ;
>   bf:publicationDate [blah] .
>
> I also don't see a need to use rdf:type (or "a" in ttl) unless those types
> provide necessary functionality. My impression is that the primary use of
> rdf:type is to make data creators feel like they've created a "record
> structure" or graph based on the type. However, it's not the rdf:type but
> the identifier for the subject that holds it all together, and any "thing"
> can be of more than one type. The type, whether implicit or explicit,
> provides semantics, not structure. My suspicion is that those semantics
> will be rarely used because of the overhead of inferencing. At the same
> time, I can see reasons, mainly having to do with the cataloging function
> that FRBR was designed for, for wanting to search and retrieve all bf:Work
> properties for a defined entity, whether or not that entity has separate
> graphs for Works and Instances. The best example of that would be combining
> data from RDA and BIBFRAME, even though they have different definitions of
> the bibliographic entities.
>
> kc
>
> --
> Karen [log in to unmask] http://kcoyle.net
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
>


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305