Print

Print


Do we have any data - how many linked data providers use the "common" vocabularies like dc, foaf, etc. to relate to those kinds of entities, versus using something else or making their own vocabulary?

 

It seems to me that those vocabularies became common because they were useful and they were THERE (bless them) for early linked data pioneers to use.  

 

In future, other vocabularies might gain ascendancy, particularly if more applications that now are based on XML or relational databases, started publishing their data as linked data and using something different.. (maybe even... BIBFRAME).  Or, coalescence around a central vocabulary might not happen, (or might happen on at a very high level, like SUMO) and instead the number of vocabularies would multiply....

 

...but a pool of available property and class vocabulary relationship "mappings" would become available to stitch things together. 

 

This is an argument that's been going on a long time (multiplicity of models...  fitted to individual conceptualizations of the world, vs. "standardization"), and there's a lot of pull in both directions.  

 

I can see the wisdom, for BIBFRAME, in defining its own vocabulary...

 

...and then provide a "mapping out" (using owl:sameAs or other relationships) to other vocabularies. 

 

I think that would accomplish what we want to do.   We are talking about making library metadata more available to the rest of the world - in terms it can use and understand, while also making the world's data more available to libraries. 

 

But, core functions of BIBFRAME have to be, to support current library services, and also to carry forward the legacy data from MARC, and I think this should have more weight.   We need definitions that really work for us. 

 

Can't we have our cake, and eat it too?   I am not sure about how expensive...  we are just talking about more triples that describe the vocabulary relationships, right?

 

There would be new tools, certainly, to help people to make the mappings and logical relationships, and people-time to do the mapping. 

 

And of course, we who have done metadata munging from one schema to another know mapping isn't always easy, and (I have read and believe!) there is danger in that "sameAs".  What is same for me (or subproperty...) may not be for you...

 

What is the "expensive" part of reasoning...  Are we talking computer expensive?  As in, response time, memory, storage space... ?

 

Of course, there is an attractive efficiency in using a common vocabulary to accomplish the same tasks.  I'm not suggesting that each �library come up with its own basic ontology.  But RDF gives so much flexibility; I would hate to try to shoehorn our data into a vocabulary developed elsewhere for a different purpose, if we don't have to.   We need to be open to possibilities of expanding the types of services we may provide by linking to different types of data than what we've had in the past (and maybe, expanding or enhancing vocabularies too!).  The more clarity and understanding we have about what our data represents, the better we will be able to build these services.

 

Meanwhile, where is that shared pool of RDF vocabulary mappings?

 

Laura

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Shlomo Sanders
Sent: Wednesday, March 13, 2013 10:33 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Reuse (or not) of existing ontologies

 

“The downside is that it would require a fair amount of inference/reasoning to work, which is currently fairly unrealistic (not impossible, just unrealistic for widespread adoption) which I don't expect to change any time in the near future.”

 

In short, it can work but will be expensive for vendors to develop, complicated and expensive for Libraries to use…

 

Instead we should works towards a common vocabulary for the most important core information.

At least for some of the core stuff… bibo, dc, foaf, etc.

 

 

Thanks,

Shlomo

 

Experience the all-new, singing and dancing interactive Primo brochure

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Ross Singer
Sent: Wednesday, March 13, 2013 15:56
To: [log in to unmask]
Subject: Re: [BIBFRAME] Reuse (or not) of existing ontologies

 

On Mar 13, 2013, at 9:36 AM, Shlomo Sanders <[log in to unmask]> wrote:

 

How can linking to RDF actually work in real life if each group has their on vocabulary?

 

Well, you align the vocabularies through RDFS, OWL, or something similar.

 

Good RDF In and display in browser, sure that will work.

But programmatic use of the data when there is no standard (or even close to a standard) vocabulary?

 

Well, this is exactly why one would propose RDF, simply because you *can* explicitly align the vocabularies.  The downside is that it would require a fair amount of inference/reasoning to work, which is currently fairly unrealistic (not impossible, just unrealistic for widespread adoption) which I don't expect to change any time in the near future.

 

-Ross.

 

Thanks,

Shlomo

 

Sent from my iPad


On Mar 13, 2013, at 15:00, "Ross Singer" <[log in to unmask]> wrote:

Owen, I can't speak for Bibframe directly, but in the case, say, of RDA, the argument against using existing vocabularies vs. rolling your own and aligning them is that you can't control the fate of vocabularies you don't own.  So if something happens to them (properties get deprecated/replaced, domain registrations lapse, etc.), you still have control of the predicates/classes you are using and can realign them as necessary.

 

Not saying that I necessarily subscribe to that philosophy (although I see its merits), but I think that is probably the argument.

 

-Ross.

 

On Mar 13, 2013, at 5:39 AM, Owen Stephens <[log in to unmask]> wrote:

 

Thanks for this J�rg

 

While obviously plans to align bibframe elements to other RDF ontologies would be welcome, I'd be very interested to understand that arguments against simply adopting existing vocabularies where they exist?

 

Owen

 

Owen Stephens

Owen Stephens Consulting

Web: http://www.ostephens.com
Email: [log in to unmask]
Telephone: 0121 288 6936

 

On 12 Mar 2013, at 09:23, J�rg Prante <[log in to unmask]> wrote:

 

From my understanding, there will be a process of "alignment" of Bibframe elements to other RDF elements. In the current phase of early Bibframe developement, I assume the focus is still on creating native Bibframe elements and vocabulary.

There have been some work closely related to Bibframe

- the W3C provenance incubator group charter http://www.w3.org/2005/Incubator/prov/charter
- ONIX for Marc21 and for RDA (ONIX in RDF still ongoing work?) http://www.editeur.org/96/ONIX-and-MARC21
- METS-PREMISE in RDF http://www.loc.gov/standards/premis/pif-presentations-2012/PREMIS-OWL-iPRES2012.pdf
- EAD to Europeana Data Model RDF http://pro.europeana.eu/documents/900548/559c18d6-e5f3-410a-9e3e-7ee74f87c302
- ...

The results would be very interesting to see them aligned to Bibframe elements.

A wider perspective would be aligning the DataCite RDF https://docs.google.com/document/d/1paJgvmCMu3pbM4in6PjWAKO0gP-6ultii3DWQslygq4/edit?authkey=CMeV3tgF&hl=en_GB to Bibframe. This would exceed the traditional MARC scope and would reveal the power of RDF by integrating research data environments seamlessly with Bibframe'd library catalog metadata.

Also expanding the view to publisher activities is helpful to get some impressions for what could be done if there was Bibframe-powered data. I saw http://prezi.com/yc35ccin0ipg/discovering-and-using-rdf-at-oreilly-media/ for an experience of a publisher when traveling a market-driven path using RDF on XML-based metadata.

J�rg

 

 

 




This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).