ParthenosWP4 / SSK

Development of the Standardization Survival Kit
9 stars 8 forks source link

Pointing to resources - TEI encoding #4

Open laurentromary opened 7 years ago

laurentromary commented 7 years ago

When referring to reference resources, we should:

bansp commented 7 years ago

The above is not entirely correct (ref won't take these attributes). Below is what I came up with for https://github.com/ParthenosWP4/BerlinWS/blob/master/linguistics/steps/step_finalize.xml but some things are not entirely clear here, either, namely:

                    <desc xml:lang="en" type="terms">
                        <term type="standard" source="standard_list" key="XML"/>
                        <term type="standard" source="standard_list" key="TEI"/>
                        <term type="activity" source="http://tadirah.dariah.eu/"
                            key="modeling">modeling</term>
                        <term type="policies" source="WP3Wizard" key="CD"/>
                    </desc>
                    <linkGrp type="generalResources">
                        <ref type="spec">
                            <term type="standard" source="http://www.zotero.org" key="ZJ7ZSJWT">FAIR</term>
                        </ref>
                    </linkGrp>
bansp commented 7 years ago

This is what I ended up with now:

                    <linkGrp type="generalResources">
                        <ref type="spec" target="https://www.zotero.org/groups/427927/parthenos-wp4/items/itemKey/ZJ7ZSJWT">
                            <term type="standard" source="http://www.zotero.org" key="ZJ7ZSJWT">FAIR principles</term>
                        </ref>
                    </linkGrp>
bansp commented 7 years ago

This is a slightly different example but under the same heading. In https://github.com/ParthenosWP4/BerlinWS/blob/master/linguistics/scenarios/sc_corpusModellingInTEI.xml , we try to reference the steps properly. It looks pretty ugly, although it's correct. Maybe indeed a central register and @key would be a better solution. (?)

Side comment: the ubiquitous Cleanup step is repeated many times here, it should eventually have parameters (at least "automatic" vs. "manual").

            <listEvent>
               <!-- <event type="scenario" ref="SSK_digitization.xml"/> -->
               <event xml:id="CMiT0" type="researchStep" ref="../steps/step_corpusComposition.xml#step_corpusComposition"/>
               <event xml:id="CMiT1" type="researchStep" ref="../steps/step_verificationAndCleanup.xml#step_verificationAndCleanup"/>
               <event xml:id="CMiT5" type="researchStep" ref="../steps/step_conversionToTEI.xml#step_conversionToTEI"/>
               <event xml:id="CMiT15" type="researchStep" ref="../steps/step_verificationAndCleanup.xml#step_verificationAndCleanup"/>
               <event xml:id="CMiT20" type="researchStep" ref="../steps/step_createWorkbench.xml#step_createWorkbench"/>
               <event xml:id="CMiT25" type="researchStep" ref="../steps/step_verificationAndCleanup.xml#step_verificationAndCleanup"/>
               <event xml:id="CMiT40" type="researchStep" ref="../steps/step_annotation.xml#step_annotation"/>
               <event xml:id="CMiT45" type="researchStep" ref="../steps/step_verificationAndCleanup.xml#step_verificationAndCleanup"/>
               <event xml:id="CMiT35" type="researchStep" ref="../steps/step_finalize.xml#step_finalize"/>
            </listEvent>
laurentromary commented 7 years ago

This is a typical case where I would rather have something elegant and semantically correct rather than keeping strictly to the rule. The combination of @source and @key is exactly meaning what we want (reference an object with a given identifier in a given source), i.e. making <ref> member of att.canonical.

bansp commented 7 years ago

I agree that the ref is not beautiful, but it does its job of pointing to an identified object. What you are proposing is perpetuating the URN/URL confusion namely to try to merge something that confirms identity with something that points.

bansp commented 7 years ago

I see ref as providing an immediate, actionable way to retrieve a resource. Whereas @source+@key act more as an identifier (something is identified as 'key' in the system present at 'source'). Compare:

Next,

My point is that they aren't fully equivalent. 'source' and 'key' are great for being used on <term>, but they produce the wrong sound when used on <ref>, it seems to me.

KlausIllmayer commented 7 years ago

in the case of tadirah, shouldn't this be:

the same for zotero:

otherwise you will loose the pointer (because seeing source and key as a way to construct a URI does need every parameter)

(and both differ, because for tadirah it is an URI parameter whereas for zotero it is a URI subpath)

charlesriondet commented 7 years ago

In fact, we want to have a parameter file that records all these base URLs, in case they change (in particular for Tadirah, it is very likely that they change one day) and also because we want to use the keys (in the case of Zotero) to query the APIs, rather than use directly the URLs.

We started it here : https://github.com/ParthenosWP4/SSK/blob/master/spec/param_SSK.xml

But I’m sure there is room for improvement, so you can have a look.

On 13 Oct 2017, at 14:12, KlausIllmayer notifications@github.com wrote:

in the case of tadirah, shouldn't this be:

source = "http://tadirah.dariah.eu/vocab/index.php http://tadirah.dariah.eu/vocab/index.php", key="tema=35&/modeling" the same for zotero: source = "https://www.zotero.org/groups/427927/parthenos-wp4/ https://www.zotero.org/groups/427927/parthenos-wp4/", key="items/itemKey/ZJ7ZSJWT" (could be discussed where source ends and key starts) otherwise you will loose the pointer (because seeing source and key as a way to construct a URI does need every parameter) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ParthenosWP4/SSK/issues/4#issuecomment-336435435, or mute the thread https://github.com/notifications/unsubscribe-auth/APGLHQ_xCY6VTMGT53DJCcYWKPRc9ensks5sr1OQgaJpZM4P2wfA.

Charles Riondet charles.riondet@inria.fr Inria (ALMAnaCH)