#441 fDecl doesn't allow att.datcat yet
TEI P5 2.1.0 says at the end of section 18.3
"Whether at the level of feature-system declarations, feature- and feature-value libraries, or individual features, it is possible to align both feature names and their values with standardized external data category repositories such as ISOcat."
However, a feature declaration can not be associated with an ISOcat data category using @dcr:datcat yet, i.e., <fDecl> [1] doesn't yet include the att.datcat [2] attribute set which <f> [3] already does.
If <fDecl> would allow @dcr:datcat it becomes possible to declare all relationships with ISOcat data categories in a feature system declaration instead of doing so highly redundant in each feature instantiation.
[1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-fDecl.html
[2] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.datcat.html
[3] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-f.html
I think this is an oversight. Piotr?
Definitely an oversight. May I grab this one?
Have added it to class: leaving it to you to add some comment / example in the chapter if you think it necessary'; otherwise just close the ticket
At the risk of disturbing the anthill let me ask: isn't adding fDecl to att.datcat analogous to adding <equiv> to it (= something that we explicitly rejected) rather than to adding <f> to it?
In other words, what's the semantics of fDecl with dcr:datcat as opposed to the semantics of <f> with @dcr:datcat? Or, in other words, shouldn't this be handled *inside* the fDecl, by an <equiv>/@uri?
To be sure, I support Menzo's need to provide equivalence/alignment information at the level of fDecl, but I'm beginning to wonder if using dcr:datcat on fDecl *directly* expresses what we want expressed here.
I would leave out the issue of <equiv> here, which is a real one.
The point of fDecl is clearly to avoid making a link on each f to assert its semantics.
Laurent, I'm not happy meddling in this ticket today, but it seems to me that the point of fDecl is to declare a feature.
The use of @datcat on fDecl seems unfortunately to mean: this fDecl acts as such-an-such category. But the fDecl is not meant to act as (= be aligned with) a category: it is the <f> that is being declared that should be aligned, not the <fDecl>.
Once again, I fully concur with the idea of expressing this information in FSD. I'm increasingly uneasy about the technical solution proposed here though. And we don't want to put in stuff that we are going to pull out in half a year, do we. :-/
Agree. I need to ponder upon this a little....
I interpret it as that the <fDecl/> declares to which data category the <f/> should be equivalent. Just like the <fDecl/> does that for the type the f value should have. If that role is better suited in TEI for <equiv/> then that could be the proper construct to use. However, it could lead to inconsistencies between the FDS and FSR mechanisms:
Given the following FSD:
<fsDecl type="WordForm">
<fDecl
name="writtenForm">
<equiv uri="http://www.isocat.org/datcat/DC-1836"/>
<vRange><vNot><string/></vNot></vRange>
</fDecl>
<fDecl
name="grammaticalNumber">
<equiv uri="http://www.isocat.org/datcat/DC-1298"/>
<vRange><vAlt>
<symbol value="singular">
<equiv uri="http://www.isocat.org/datcat/DC-1387"/>
</symbol>
…
</vAlt></vRange>
</fDecl>
</fsDecl>
and FSR
<fs type="WordForm">
<f name="writtenForm">
<string>clergyman</string>
</f>
<f name="grammaticalNumber">
<symbol value="singular"/>
</f>
</fs>
this FSR and FSD combination should be equivalent to
<fs type="WordForm">
<f name="writtenForm" dcr:datcat="http://www.isocat.org/datcat/DC-1836">
<string>clergyman</string>
</f>
<f name="grammaticalNumber" dcr:datcat="http://www.isocat.org/datcat/DC-1298">
<symbol value="singular" dcr:datcat="http://www.isocat.org/datcat/DC-1387"/>
</f>
</fs>
Of course any tool interpreting the FSD can make this transition from <equiv/> to @dcr:*, but is it really needed? Introducing <equiv/> would touch maybe more then wanted, e.g., in my example I also used <equiv/> to express the data category equivalence for the singular symbol. As FSR and FSD share <symbol/> <equiv/> would also become part of the FSR. The same is true the other way around @dcr:* is available for <symbol/> in the FSR so also in the FSD. In my view it would be strange to use <equiv/> in one part of the FSD and @dcr:* in another part ...
Just my 2 cents ...
I take the point about <equiv>. On the other hand, I also see an issue concerning the variable interpretation of the dcr: attributes, where, I believe -- and I think this belief is shared by some members the Council, after some exchanges on the topic in the past and now -- there should be one simple interpretation ("*I* am aligned with this-and-that").
What we have here is, I daresay, an obvious case where we should *not* feel ready to commit ourselves to one view -- there's still a few paths left open. I would therefore like to follow a suggestion that I have got, to withdraw Lou's modification before the release, and bring it back after the release, while leaving this ticket open.
Where do we stand with this? I think we need to alter slight the policy "I am this" when it applies to element declaring the semantics of others (equiv and fDecl are two similar cases). For tsuch elements, the dcr: attributes would mean: "what I declare here is equivalent to this entry in the DCR"
That would mean semantics conditioned upon semantics, a pretty nasty dependency.
How about targetting this squarely and setting up something analogous to @targetLang, with the precise semantics mentioned above?
Can you elaborate on that? You mean having an additional dcr: attribute?
After having pondered on this for a while, I think now that it might be good to make ISO FSD (ISO 24610-2:2011) aware of other ISO standards, as is, well, standard.
This time, it would be nice if ISO FSD was made aware of the existence of ISO DCR and allowed for what we've talked about in this ticket. It seems to me that this is the direction where the effort should be going, otherwise the TEI is pressed into patching what other bodies should have fixed by now.
Well in this case, ISO FSD will just take up what the TEI suggests, because a) this is where most appropriate experts are and b) we should normally expect more reactivity on the side of the TEI. So for me the TEI is the place to experiment/implement. We should thus not procrastinate this too long...
I agree that FSD is in serious need of an update. It has not changed
substantially for many many years. I'm just not sure who the "other
bodies" are who might do this -- the workgroup in TC37 has not so far as
I know done much lately. It's a joint ISO/TEI workgroup, but it needs
revitalising from both sides.
On 12/08/13 10:56, Piotr Banski wrote:
Related
Bugs: #441
So, back to the actual issue. How to mark on fDecl the equivalence to an ISOCat entry. Piotr rejects the existing dcr: attributes since he says it is not the appropriate semantics. Is there a consensus on this? If yes, we need an extra mechanism. Another attribute? also in the dcr: namespace?
BTW, it's not that I had the whim to reject the use of the existing dcr: attributes: I have merely pointed at considerations and decisions made in an analogous case.
To push the point further: there is nothing illogical in placing @dcr:datcat on an fsDecl or fDecl, to make sure that they are interpretable as data containers for declarations of feature structures or of features. That is in full accordance with DCR principles, and, in fact, this point alone should suffice to cut the discussion on the initial suggestion, and redirect it towards looking for a place and a method to define something like @targetDatcat.
Apart from the status of ISO/TEI FSD, one more issue that may need to be considered is that it may be expected that it's the "new" piece of the standards puzzle that should be responsible for defining bindings for the other standards, rather than forcing them to update.
ISO DCR has done a good job by defining and namespacing its two attributes that can now be plugged into other descriptions. Possibly, what Laurent has mentioned above may be a good further step: to expect ISO DCR to update and extend its set of {@datcat, @valueDatcat} with two more attributes that can be used in schemas, notably in ISO FSD: {@targetDatcat, @targetValueDatcat}.
Last edit: Piotr Banski 2013-08-12
OK. Than let's define a proposal for these two attributes, liaise with Menzo and Sue-Ellen to fine-tune and have this adopted on booth side.
Here below, I put a comment from Menzo Windhouwer:
[quote]
If I understand correctly there were concerns due to the implicit indirection from a schema declaration to the instances, e.g., if you link a DC with @dcr:datcat to an element declaration in a schema it actually implies that the instance is linked to this DC. It's now proposed to make this explicit by using @dcr:targetDatcat and @dcr:targetValueDatcat. I've added support for this to the DC Reference schema. See DC Reference schema version 1.2 at (on the ISOcat test server, not yet on isocat.org):
So these could be used by fDecl now, e.g.,
<tei:fDecl name="partOfSpeech" dcr:targetDatcat="http://www.isocat.org/datcat/DC-1345">
<tei:vRange>
<tei:vAlt>
<tei:symbol value="..."/>
<tei:symbol value="commonNoun" dcr:targetValueDatcat="http://www.isocat.org/datcat/DC-1256"/>
</tei:vAlt>
</tei:vRange>
</tei:fDecl>
Do notice that as the tei:fDecl schema reuses tei:vRange the value declarations, e.f., tei:symbol in this case, should support both the dcr:target attributes and the 'old' dcr: attributes as these elements can also appear in an instance.
Please let me know if I misunderstood or other solutions are preferred. If it's all correct I'll include this in the next update of isocat.org. And also update the FSD support of RELISH LMF (see http://tla.mpi.nl/relish/lmf/).
[/quote]
Here is the fDecl example that gone missing in the previous post:
Hi, All,
Any consensus on this? I'm preparing an isocat.org update and would like to know if I can include the changes for TEI in the DC Reference RELAX NG schema.
Thanks in advance,
Menzo
I think your last proposal did not lead to any criticism. I would say you can move ahead. @others?