Re: Itemprop for person

Hi Karen,

Thanks for the explanations! So, is there a different rule for subject indexing of books (one persona should be used) than for description of creators (different persona can be used)? If yes, it's a bit strange.

Anyway, my point in 2 is indeed about (somewhat) controling value: if library mark-up tries to reproduce persona patterns that are really specific to library-land and not relevant for more general mark-up consumption cases, then library mark-up risks being not very popular...

Cheers,

Antoine


>
>
> On 11/27/12 1:09 AM, Antoine Isaac wrote:
>
>> 2. We can ask libraries to munch their various persona into "real"
>> person records, before exporting the data using schema:person for
>> representing real persons.
>
> For subject access (subject headings and classification) US libraries use only one "persona" where more than one has been used. It is not necessarily the "real" person -- it is the "best known" -- so that in subject classification all works by or about Twain and Clemens are under Twain. You can see which is used in the authority record because "Clemens" is marked "not for use for subject access."
>
> That said, I still don't understand the necessity. Remember that schema.org will mark up the library data that is there, as it is used by libraries on their web pages. It's not about exported data, it's about marking up what you show your users. This already means that libraries in Russia will have author Лев Никола́евич Толсто́й, and in the English-speaking world we will have author Leo Tolstoy (or some variant on that). These are the same real person, but I don't think that's the point -- the point is that schema.org allows you to mark up your data, it doesn't control the value space, and the value space is going to be messy.
>
> kc
>
>>
>> While 2 may first sound harsh on our community, I believe this we can
>> name it "reasonable" when library data goes out and meets more general
>> scenarios. Also, I believe that current initiatives (e.g., every project
>> that seeks to align name authority with DBpedia) are working towards
>> making this possible, even though it will be sometimes bumpy.
>>
>> An important decision criterion would of course be the usage scenarios
>> there are, and their accompanying information needs, either voiced by
>> users or extrapolated by the search engines serving these users. In
>> other words, what is the take of schema.org on the topic? And how
>> leading commercial sites are treating personas? (I'm offline while
>> writing this so can't check, alas).
>> I suspect anything libraries come up on this issue will have little
>> weight compared to what search patterns established by Amazon and the
>> likes.
>>
>>
>> Note that for other kind of entities like places I'm slighlty less sure.
>> Maybe there are some applications that would benefit from not trying to
>> geo-localize places that are not on this Earth.
>>
>> Best,
>>
>> Antoine
>>
>>
>>
>>> I'd argue for Fictional Things.
>>>
>>> On 14 Nov 2012, at 18:27, Kevin Ford wrote:
>>>
>>>> we need to make a strong case for enabling the possibility of
>>>> fictional medical studies or postal addresses, among other things.
>>>
>>> Fictional place names certainly exist -- as in Winnie the Pooh:
>>> https://en.wikipedia.org/wiki/File:100acre.gif
>>>
>>> Or even styled as (fictional) postal addresses:
>>> 4 Privet Drive
>>>
>>> For a Fictional Medical Study, the backstory of the games Portal and
>>> Portal2 come to mind. In fact, game backstories would often provide
>>> examples, e.g. the studies at locations such as these
>>> http://en.wikipedia.org/wiki/Locations_of_Half-Life
>>>
>>> Or I suppose this might do:
>>>
>>> https://www.facebook.com/pages/QASE-fictional-BioMedical-Research-Facility/169647519762414
>>>
>>>
>>> (maybe http://www.facebook.com/r.php?fbpage_id=169647519762414&r=111
>>> <http://www.facebook.com/r.php?fbpage_id=169647519762414&r=111> but
>>> that gives a loginwall):
>>>
>>> Pardon the excessive examples. It's the end of the day.
>>>
>>> :) -Jodi
>>
>>
>>
>

Received on Tuesday, 27 November 2012 16:06:16 UTC