Re: Discussion about previous proposal

Hi Richard,

This is really helpful, and does clear up some of the confusion I was under, thanks. 

However, now I think I understand it, I can see a  fundamental issue it raises for the Archives Hub…. If we want to apply schema.org markup to an ‘archiveItem’ we won’t know what the item is - whether it is a notebook, letter, series of correspondence, or an article or book (which would usually be annotated in some way in order to be in an archive in the first place).  So you say:

>  • What is the item (separate from it being in an archive)  - a Book, an Article, a Painting, a Vehicle ?
> Choose the appropriate Schema Type and use that type’s properties to describe the item.

But we don’t know what it is because we aggregate descriptions from over 300 repositories and they very rarely put down the type in the description. I think if anyone was going to apply schema.org to already existent archive catalogue information, they would have the same problem. Especially because the unit of description below the collection is usually an aggregation anyway, not one item. 

It seems to me, if I’ve got this right, that CreativeWork is more generic and you can apply various properties to it without a more specific type? Or do you have to choose a more specific type? 

cheers
Jane



> On 16 Feb 2017, at 10:41, Richard Wallis <richard.wallis@dataliberate.com> wrote:
> 
> Hi Jane,
> 
> In your first email, your example Schema.org description of an ArchiveCollection is a good start, utilising properties inherited from its super types (CreativeWork and ArchivedItem).
> 
> Taking the points in your 2nd email:
> 
> 1 & 2.. Should I not worry about the class being intangible? - No.   maybe I’m getting too hung up on describing something physical under the class of intangible?  - Yes.
> So what about DateCreated, inLanguage, genre, creator, about, etc?  These are the properties I would want to use at any level when describing archives - So you should.
> 
> These issues, often a point of early confusion for those new to using Schema.org, come under the heading of Multi-Type Entities (MTEs) - Until recently not fully recognised by Google’s testing tool, so historically not well used.  A MTE is a Thing that is described as being of more than one type. 
> 
> Applying MTEs in practice for an item in an archive, the process would flow something like this:
>  • What is the item (separate from it being in an archive)  - a Book, an Article, a Painting, a Vehicle ?
> Choose the appropriate Schema Type and use that type’s properties to describe the item.
> 
>  • As the item is in an archive, also add the ArchivedItem Type, which then makes available some more properties to enable you to describe the archive related attributes of the item.
> Practically this is achieved in the various data serialisations thus:
>     Microdata: <span itemscope itemtype=‘http://schema.org/Painting’

> >
> 
>           <link itemprop=“additionalType” href="http://schema.org/ArchivedItem"/>
>           <link itemprop=“additionalType” href="http://schema.org/ArchivedItem"/>
>   RDFa: <body vocab=“http://schema.org” typeof='Painting ArchivedItem'
> >
> 
>   JSONJD: “@type”: [“Painting”,”ArchivedItem”]
> 
> 3. ArchiveCollection is defined as being a subtype of both CreativeWork and ArchivedItem making those properties available
> 
> It seems like you’re saying that archived item is a type, rather than a ‘thing’, 
> In terms of the Schema.org vocabulary, ArchivedItem is defined as a Type.  However in practice is use could be described more appropriately as a qualifying type.  I would expect it to be unlikely to be used in isolation.  Most ArchivedItems will also be a type of thing in its own right - a Book, Document, Product, etc.
> You would use it to apply archived-ness to the description of items in an archive.
> 
> 
> Hopefully the above some of the thoughts you share in the rest of the email.
> 
> I understand that this [Schema.org] approach is a little confusing when first encountered, especially when starting at a result [proposal], and working backwards to first principles.  Normally when engaged to help projects with Schema.org understanding and application, I start at the beginning.  ;-)
> 
> ~Richard.
> 
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com

> Linkedin: http://www.linkedin.com/in/richardwallis

> Twitter: @rjw
> 
> On 15 February 2017 at 14:54, Jane Stevenson <Jane.Stevenson@jisc.ac.uk> wrote:
> Hi all,
> 
> I’m still not clear on the proposal.
> 
> ArchivedItem has its own properties, which include accessAndUse, itemCondition, itemDescription, itemProvenance.  I can see these are ‘archive specific’.
> 
> 1. Should I not worry about the class being intangible? An intangible thing doesn’t have a Location, Condition or Provenance. I do get the basic premise that it doesn’t matter too much in schema.org what things are called (e.g. the localBusiness class being used for an archive). So maybe I’m getting too hung up on describing something physical under the class of intangible? I thought first of all you were saying that this was only to describe it as ‘partOf’ something, but clearly it is also to describe its physical characteristics.
> 
> 2. ArchivedItem also inherits ‘thing’ properties - name, description, url.
> So what about DateCreated, inLanguage, genre, creator, about, etc?  These are the properties I would want to use at any level when describing archives - from the collection to the series to the item.
> 
> If we take DateCreated, which is a key descriptor, the problem we have is that it is used for a creative work. But If we are going to use schema.org to help with discovery of archives through search engines, I think date created is a useful property to have.
> 
> 3. ArchiveCollection can in theory be a single item anyway, and then you may want to use e.g. itemCondition, itemDescription.
> 
> For the Archives Hub we tend to think in terms of an archival unit - and that can be at any level. A collection could be one item, or a collection may only be described at series level. We simply want to apply schema.org to every unit of description, and I had thought that we would be able to do this without thinking in terms of whether the unit is a collection or item. I’m also not sure where that leaves a series, sub series, file….
> 
> - Any type of *thing* could be in an archive.so archive specific attributes cold not be expected to be added to a single Type.
> 
> But you are adding archive attributes to the single type of ArchivedItem….?
> 
> - Using the Schema.org practice of Multi-Typed Entities (MTEs) those
>   archive specific properties can be attached to a qualification type -
>   Archived Item in this case.
> 
> But here you seem to be saying that we can add archive specific properties to ArchivedItem - so they can’t be added to a single type but they can be added to ArchivedItem, which is a type?   (clearly I’m not getting something here).
> 
> It seems like you’re saying that archived item is a type, rather than a ‘thing', as Owen was saying. But the properties seem very much to be describing a thing.
> 
> - *CreativeWork*, *Product*, etc. would be too specific
> 
> But this comes back to the requirement to use the CreativeWork properties.
> 
> 
> cheers,
> Jane
> 
> Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
> 
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
> 

Received on Thursday, 16 February 2017 11:04:35 UTC