Make sameAs value of period definition editable?

[atomrab]

The sameAs field is currently not editable. When we add the Library of Congress period assertions extracted from the LCSH, each of those subject headings is available as linked data (though the citation is not linked data). Under what circumstances will that field be editable, and how do we add LD URIs without it? I put the URI in the source locator field and the URL for the LCSH website in the URL field, but it seems like we'd want to use the sameAs field in this case.

[ptgolden]

Right now, you can't. You can add the URI to the linked data field and add optionally add a note to the collection/period explaining this connection, but Ryan and I decided that validating linked data for the sameAs field was too complicated and rarely needed. We could definitely implement this in a later stage, however.

Or, @rybesh, if your thoughts have changed, I could be convinced otherwise.

[atomrab]

You can add the URI to the linked data field and add optionally add a note to the collection/period explaining this connection

You mean the "source locator" field, right? Unless I'm missing something, we don't have a "linked data" field in the period definition add/edit window. The only place linked data is mentioned is in the explanation text in the grayed-out Same As field ("Linked data for this period"), but this is the one that's not editable.

[ptgolden]

Sorry, I meant to the URL field

On Aug 5, 2015, at 1:34 PM, atomrab notifications@github.com wrote:

You can add the URI to the linked data field and add optionally add a note to the collection/period explaining this connection

You mean the "source locator" field, right? Unless I'm missing something, we don't have a "linked data" field in the period definition add/edit window. The only place linked data is mentioned is in the explanation text in the grayed-out Same As field ("Linked data for this period"), but this is the one that's not editable.

— Reply to this email directly or view it on GitHub.

[rybesh]

For all our Linked Data sources, the url and sameAs values are identical, so for now we are just recording them using the url field in the client, and we can copy them to sameAs later. In the next phase, addressing this better will be part of a general overhaul of dealing with sameAs, derivedFrom, and the process of building a period collection for a specific project (see issue #79).

[atomrab]

Does this mean that it's preferable to use the .html resolution of a non-HTML URI, like the ones at LoC, in that field? Or should we enter the base URI, assuming that the source will resolve it?

On Friday, August 7, 2015, Ryan Shaw notifications@github.com wrote:

For all our Linked Data sources, the url and sameAs values are identical, so for now we are just recording them using the url field in the client, and we can copy them to sameAs later. In the next phase, addressing this better will be part of a general overhaul of dealing with sameAs, derivedFrom, and the process of building a period collection for a specific project (see issue #79 https://github.com/periodo/periodo-client/issues/79).

— Reply to this email directly or view it on GitHub https://github.com/periodo/periodo-client/issues/80#issuecomment-128859959 .

[atomrab]

Also, how will we distinguish an LD URI in the URL field from a normal non-LD webpage with no RDF etc representation? The French values in ARIADNE are all from URLs but are not LD. Do we only put those into source locator, and reserve the URL field for LD?

On Friday, August 7, 2015, Adam Rabinowitz adam.rabinowitz@gmail.com wrote:

Does this mean that it's preferable to use the .html resolution of a non-HTML URI, like the ones at LoC, in that field? Or should we enter the base URI, assuming that the source will resolve it?

On Friday, August 7, 2015, Ryan Shaw <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

For all our Linked Data sources, the url and sameAs values are identical, so for now we are just recording them using the url field in the client, and we can copy them to sameAs later. In the next phase, addressing this better will be part of a general overhaul of dealing with sameAs, derivedFrom, and the process of building a period collection for a specific project (see issue #79 https://github.com/periodo/periodo-client/issues/79).

— Reply to this email directly or view it on GitHub https://github.com/periodo/periodo-client/issues/80#issuecomment-128859959 .

[rybesh]

1. For linked data URLs that resolve to HTML pages, you should enter the permalink for the resource, not the address of the HTML page it resolves to when you open the permalink in the browser.
2. If the individual definitions have individual unique URLs, put them in the URL field for the definition, even if they are not linked data. Yes, in theory this means that we have no way to distinguish which definition URLs point to linked data, but in practice there are only a few linked data sources, and I don't think it will be a problem. But if you're concerned you could add an editorial note.

[ptgolden]

Ryan and I talked about this issue this afternoon, and we're both in favor of removing sameAs from period definitions for a couple reasons..

1. It's not actually true that these URIs are exactly the same, which is what rdf:sameAs is saying. Our period is definitionally different from the source period-- we are adding information in our curatorial fields such that our period is kind of a gloss over the source material.

2. We're mostly just using it to denote that the IRI in the sameAs field is a linked data representation of the same period. The URL field should contain an IRI that identifies the resource that is serving as the source material for this period. Whether or not that source does content negotiation (i.e. serves RDF or other representations of that resource) is not our concern

[ptgolden]

It's not actually true that these URIs are exactly the same, which is what rdf:sameAs is saying

I was writing in a hurry. I meant that it's not true that the resources identified by our IRI, and the sameAs IRI are exactly the same