Re: new itemscope or not?

I love this!

*goes exploring*

On Sep 7, 2012, at 5:38 PM, Thad Guidry <thadguidry@gmail.com<mailto:thadguidry@gmail.com>> wrote:

In Freebase, we went for "classing" all identifiers with a simple enumeration type (a container element really).  Enumeration is not the same thing as some programming languages call Enumerated Types... this idea is different....  The name "enumeration" refers to the fact that the namespace associated with the enumerated property enumerates instances of the type.   More about Enumeration is here: http://wiki.freebase.com/wiki/Enumeration

In Freebase here,    https://dev.freebase.com/type/enumeration?schema

you can click on the + sign for Commons and Bases and scroll down and see all the enumerations of most of the Freebase types.  Things like NY Times ID, Twitter ID, Internet Pinball Machine DB ID...etc.

and they are all enumerated to a namespace (just one of the properties available)

/authority is a specific namespace in Freebase, but that's cause and effect of its graph database backend design, I think.  An authority is what gives us the namespace that has an identifier key, like as shown here, https://dev.freebase.com/authority?keys

+1  I agree with Richard.... implementing an Identifier class in Schema.org<http://Schema.org> (not sure if it should go on Thing or not) would be similar to that in Freebase as an enumeration type.  The Linked Data folks will need this kind of class, everyone knows it.  So my vote is to begin work on it to make it so in Schema.org<http://Schema.org>.

Hopefully I stated all the above accurately regarding Freebase identifiers and authorities...I think the idea is to move stuff under the /authority namespace where appropriate ... (I didn't see LoC at the /authority level but if I am wrong on anything above, I'm sure Jason Douglas on list will set me straight :-)

On Fri, Sep 7, 2012 at 4:00 PM, Dawson, Laura <Laura.Dawson@bowker.com<mailto:Laura.Dawson@bowker.com>> wrote:
I think we need to test different scenarios and see what the results are - get very familiar with the drawbacks and benefits of each approach, and then...either pick one or figure out a way to accommodate both depending on usage...


On Sep 7, 2012, at 4:51 PM, Richard Wallis <richard.wallis@oclc.org<mailto:richard.wallis@oclc.org>> wrote:

This thread is playing out some of the thoughts I have been having around the issue of representing identifiers for a while.  It is a classic “I would not of started from here” problem.

In the ideal world everything would have it’s own identifier that everyone would recognise as being unique and in the Schema/RDF world it would be a resolvable http URI.

However, we have been creating identifiers for things, people, etc, for decades and continue to do so.  Often these identifiers can be considered as things in their own right.  For example, an ISBN has properties such as issuing authority, organisation it was issued to, issue date, book, and of course the string of characters which is the number itself.  This is a pattern that is repeatable in a lesser or greater degree for many identifiers from EAN’s to social security numbers.

One approach to associating these numbers is the one taken with Book.  Predefine what identifiers can be associated with a thing and provide an attribute for it – Book:isbn.  The problem with this approach occurs when the addition of more of these identifiers becomes appropriate, as we are seeing in this conversation about Person – do we add attributes for ISNI, VIAF, ORCID, Social Security Number, etc?

The other approach would be to implement an Identifier class enabling the description and associated attributes of identifiers from any scheme, plus having the ability to associate many different identifiers.  As Ed says, this may be applicable for most classes of thing, so why not add an Identifier property to the Thing class.

Essentially it is choice between constrained simplicity (Book:isbn) which prevents you from adding identifiers not thought of at schema definition time or; flexibility which introduces a complexity of indirection that many would not expect.

~Richard

On 07/09/2012 20:19, "Dawson, Laura" <Laura.Dawson@bowker.com> wrote:

So many identifiers are not URLs. They can be related to URLs (as DOIs) but they are not URLs themselves.

I would be reluctant to have VIAF be "the" person identifier.

On Sep 7, 2012, at 3:15 PM, Jeni Tennison <jeni@jenitennison.com> wrote:


On 7 Sep 2012, at 20:03, Ed Summers wrote:
It would be interesting to know if the HTML spec allowed multiple
identifiers, similar to how other HTML attributes work:


"The itemid attribute, if specified, must have a value that is a valid URL potentially surrounded by spaces."

http://www.w3.org/TR/microdata/#attr-itemid

So that would be 'no', not according to spec.

I've often wondered whether the schema.org<http://schema.org/> 'url' property is meant to be synonymous with itemid. I'm not sure what happens in schema.org<http://schema.org/> interpreters when you specify one/other/both/multiple urls...

Jeni

Laura Dawson
Product Manager, Identifiers
Bowker
908-219-0082<tel:908-219-0082>
917-770-6641<tel:917-770-6641>
laura.dawson@bowker.com<mailto:laura.dawson@bowker.com>






--
-Thad
http://www.freebase.com/view/en/thad_guidry

Laura Dawson
Product Manager, Identifiers
Bowker
908-219-0082
917-770-6641
laura.dawson@bowker.com<mailto:laura.dawson@bowker.com>