[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legaldocml-comment] Comment on Akoma Ntoso Naming Convention
Dear Tara,
On 05/giu/2015, at 23:15, Tara Athan <taraathan@gmail.com> wrote:
> Rather than embedding further comments, I'll copy here:
>
>> [FV] We stand by our choice of using for IRI references those terms and productions that have been used for URI references and that can be used for IRI references unchanged.
>
> I completely agree with your choice of IRIs throughout. I only wished to emphasize that your citations should therefore be primarily to RFC 3987, as well as this being an additional justification for not using the terminology of "absolute-path reference" in ANNC.
>
Ok. That's settled then. We will refer to 3987 with greater care.
>> [FV] We introduced and relied from the ground up on FRBR exactly for this reason. FRBR is VERY IMPORTANT for the Akoma Ntoso Naming Convention.
>
> I don't see how the use of FRBR affects the argument about resolution of IRI references. An internet resource, using "resource" in the sense of RDF, may denote an abstraction or something physical. In either case, there is no difference in regarding to how IRI references to it are handled. And in the case of global IRI references in an Akoma Ntoso document, every one is resolved in the same way - by prepending a particular scheme (http://) and authority (varies from one provider to another, but is the same for all global IRI references in that document).
Correct. Yet, somewhere in the following some fundamental aspects of FRBR do provide an answer to your doubts.
>> [FV] AKoma Ntoso IS NOT INTERESTED in having direct resolution of IRI references to physical IRIs
>
> I don't know what you mean by "physical IRIs".
I hoped it would be clear. Physical IRIs = IRI of physical files. IRIs of Items. The dereferenceable identifier. The result of the mapping part of the resolution of Akoma Ntoso IRI references.
>> [FV] /akn/country/act/X/language@/og.xml
>
> Let me see if I have this straight. Since you say that only the absolute IRI is the identifier, then it is possible for different resolvers to refer to quite different things for the same global IRI reference, correct? So there could be two different IRIs with the same path component
> http://example1.org/akn/country/act/X/language@/og.xml
> http://example2.org/akn/country/act/X/language@/og.xml
>
> with quite different content.
No. We must consider FRBR and the existing difference between completion and mapping in ANNC resolution.
The IRIs you provide refer to the SAME Manifestation. It is true that the Item mapped by example1.org could be a different one than the Item mapped by example2.org. But since they are different Items of the same Manifestation, they are byte-by-byte identical to each other, and therefore accessing this one or that one would not provide different content.
If this is not the case, then either example1.org or example2.org is lying, i.e., it is failing to provide a correct resolution of the reference.
> There seems to be an assumption that by some mechanism, there will be designated one or more domains which are guaranteed to have authoritative content for a particular path, while for other domains, it is "buyer beware". And that mechanism to designate which domains may be trusted for which paths is outside the scope of ANNC. Is this correct?
... er... I am not sure to follow. There is a great deal of autonomy and leeway in how individual resolvers may act upon an IRI reference you provide them. There are at least two ways where they could behave differently:
1) given an incomplete IRI reference (e.g., a Work-level or an Expression-level reference), they could complete it differently. In particular, not only they could choose different languages and/or versions for the same reference, they could choose different Manifestation sources that could provide with rather different Manifestations. This is licit and it is considered a richness, not a limitation, of the resolution process.
2) given a complete IRI reference (e.g., a Manifestation-level reference), they could map it differently. For instance, given the same Manifestation-level reference to an European law, a Swedish server may provide you with the Item-level IRI from a Swedish repository, a Spanish server may provide you with an IRI from a Spanish repository. But since they are byte-by-byte identical, this is not an issue for the end user.
As usual, as it happens with ANY intermediary between the client and the provider of a service, it is buyer beware: the intermediary could fail to provide a service, it could provide the wrong service, it could hide malicious services while appearing to provide the right one.
This is true everywhere. Consider for instance using a URI shortener service. At some point it could cease to provide URI resolution, it could mangle irremediably the resolution (if it started to reuse existing short URI, for instance), it could secretly inject malicious content through a fake two-steps redirect. Every URI shortener service is buyer beware, in this sense.
> Assuming I have the correct idea now, what is missing for me in the document is guidance (which could be informative rather than normative) on how to refer to Akoma Ntoso documents, or parts thereof, externally - from non-Akoma Ntoso documents, that are not served from the same domain as the AKN document. As you say, an absolute IRI is required, so in this case the domain must be presented somehow and expressed in the reference.
In order to access an Akoma Ntoso document, you do NOT need the Akoma Ntoso Naming Convention. Every existing, physical Akoma Ntoso document has its own IRI which is plain and simple and traditional.
But should you want to use the AN naming convention, you are empowered to address and dereference an Akoma Ntoso document (or even a non-Akoma Ntoso document) by using an incomplete reference, and letting some magic component of the architecture complete it for you in a manner that is consistent with your desires, context and requirements (e.g., in terms of human language, data format and validity period). If this is the case, you CAN avoid using the Item-level IRI of the document you seek, and use an ANNC IRI reference.
In order to do so, you MUST find an Akoma Ntoso resolver and you MUST point your reference to it, because an Akoma Ntoso IRI reference does not indicate a resolver: you must choose one. Also, there is NO authoritative Akoma Ntoso resolver. By design.
> In the example you provided of the resolver at http://akresolver.cs.unibo.it/, one of the demos there results in the absolute IRI
>
> http://akresolver.cs.unibo.it/akn/uk/act/pga/2014/2/eng@2014-01-30
>
> Neither the rendered page nor the source of that page show me the Akoma Ntoso XML, but my understanding is that if this were completed, then the resulting absolute IRI denotes some piece of Akoma Ntoso XML (as a manifestation), whereas the original IRI denotes the expression.
The IRI reference you mention is incomplete, since it is an Expression-level IRI reference. Therefore akresolver does THREE things:
1) it completes the incomplete reference by creating a full Manifestation-level reference (still an IRI reference):
/akn/uk/act/pga/2014/2/eng@2014-03-30;hmso.html
(which is shown as the first item of the main menu in the center of the page).
2) it maps the Manifestation-level reference above onto the absolute IRI of an Item representing it
http://www.legislation.gov.uk/ukpga/2014/2/2014-03-30?view=plain
(which is shown as the second item of the main menu in the center of the page).
3) it delivers an HTML page wrapping such absolute IRI within an iFrame and providing some additional content.
Wrapping the item in an iframe is only one of the many possible actions the resolver may take. For instance, it could just redirect the request to the IRI similarly to an URL shortener. This option is available through the preferences (menu on the right).
Interestingly, the returned text is NOT an Akoma Ntoso document, it is a plain HTML document (the Akoma Ntoso Naming Convention works with any media type, not only Akoma Ntoso document. The document you chose is straight HTML).
> If I have all this straight, then I would suggest that something like the following be added to the document for clarification purposes, most logically in the Scope section.
>
> "The scope of this specification is the syntax and semantics of the path components of IRIs that refer to Akoma Ntoso concepts and resources on the internet. In keeping with best practices of the Web, the identifier of an Akoma Ntoso concept or resource is always an absolute IRI. Although the authority portion of such an IRI conveys significant information concerning the provenance of the concept or resource, the details of this are outside of the scope of the ANNC specification."
I appreciate your text proposal. However it simply does not fit the narrative in my mind.
1) the Akoma Ntoso Naming Convention does not only refer to Akoma Ntoso concepts and resources on the Internet.
2) It certainly does not discuss path components of IRIs
3) The authority portion of the IRI does NOT conveys significant information about the provenance of the concept or the resource.
In fact:
1) the Akoma Ntoso Naming Convention can and has been successfully applied to document well outside the Akoma Ntoso data format (inasmuch as by Akoma Ntoso we refer to the specific XML vocabulary called Akoma Ntoso). On purpose, the examples on akresolver.cs.unibo.it are of PDF and HTML documents. There is nothing "Akoma Ntoso XML" in the Naming Convention (well, there is, section 5 about ids, but this is not the topic of discussion here).
2) The Akoma Ntoso Naming Convention, by design, describes path components of IRI references, not of IRIs. By design they are global (i.e., they start with a slash).
3) The provenance information of the concept or the resource is rather complicated, and its identification is split in separate parts, in adherence to the fundamental FRBR concepts implied:
a) the provenance of the manifestation is specified by the Manifestation date and/or Manifestation source fragments of the IRI reference (in the above example, no Manifestation date, but there is a manifestation source: the 'hmso' bit).
b) the provenance of the expression is specified by the Expression date and/or Expression source fragments of the IRI reference (in the above example, no Expression source, but there is an Expression date: the '2014-03-30' bit).
c) the provenance of the work is specified by the Work date and Work actor and Work document type fragments of the IRI reference (in the above example, the Work source ('pga'), and the Work date: the '2014' bit).
Nowhere the authority part of the resolver engine plays a role in the establishment of the provenance. Of course the resolver could provide biased resolution, e.g. suggesting a peculiar source for the manifestation, or it could provide false resolution, e.g., mapping the correct Manifestation IRI reference to an incorrect Item-level absolute IRI. The first behavior is licit, the second is not. Neither is under the control of the specification.
> However, the following paragraph was/is still particularly confusing to me.
> " Since it is a requirement of Akoma Ntoso that all existing FRBR items of a Manifestation be byte-per-byte identical to each other, it is a natural consequence that it is not abstractly relevant which resolution engine dereferences the actual Item whose IRI is resolved out of a Work-level, an Expression-level, or a Manifestation-level IRI reference. This, in practice, means that protocol and authority are, in resolution, not contributing information, and are thus interchangeable."
Yeah, it could be confusing. It requires some serious mind shift. In particular, it requires relinquishing the idea that a document is a thing, say a file. A document is a concept. Indeed, it is many different concepts. Indeed, the term "document" is intrinsically tainted by so many meanings, that FRBR has been invented so as to provide a non-ambiguous set of terms for concepts we use "document" for. This is why FRBR is important for us. Unless it is clear or irrelevant we do not use the term "document", we use Work, Expression, Manifestation or Item instead.
> First, I didn't see anywhere (else) the requirement stated "all existing FRBR items of a Manifestation be byte-per-byte identical to each other"
The Item is most often associated to the idea of the result of a copy operation. E.g., in [1], we find:
"Changes that occur deliberately or even inadvertently in the production process that affect the copies result, strictly speaking, in a new manifestation. A manifestation resulting from such a change may be identified as a particular “state” or “issue” of the publication. Changes that occur to an individual copy after the production process is complete (e.g., the loss of a page, rebinding, etc.) are not considered to result in a new manifestation. That copy is simply considered to be an exemplar (or item) of the manifestation that deviates from the copy as produced."
The copy process of electronic record is nowadays perfect (copies of a file are byte-by-byte identical), and it is pretty much established that changes in the system metadata about a file (e.g., creation date, file name, etc.) do not result in different manifestations, while changes to the byte stream, requiring you to open the file with a tool, would result in a new manifestation. Consider for instance [2]:
"frbr:Manifestations correspond to a specific bit pattern. If a file is an exact copy of another file, they have the same frbr:Manifestation. An frbr:Item is a specific copy of information stored somewhere or transmitted through a communication link. If a copy of a frbr:Item is made, it results in a new frbr:Item".
[1] http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf, pag. 23
[2] McCuskerJ., et alii, Functional Requirements for Information Resource Provenance on the Web, in "Provenance and Annotation of Data and Processes" (P. Groth, J. Frew eds.), 4th International Provenance and Annotation Workshop, IPAW 2012, Santa Barbara, CA, USA, June 19-21, 2012, Revised Selected Papers, Lecture Notes in Computer Science Volume 7525, 2012, pp 52-66, ISBN: 978-3-642-34221-9
> When you talk about all existing FRBR items of a Manifestion, I think of "a Manifestation" being identified by an absolute IRI, so a different absolute IRI having the same path component could identify a different Manifestation (of the same Expression), which would naturally have a different Item as well. So it appears to me that the authority component of the IRI is extremely important.
Nope. Also, please notice that there is NO RELATION WHATSOEVER between the absolute IRI os an Item and the IRI reference of its Manifestation. They are completely different thing, they do not even look like each other, and only the Manifestation-level reference is in the ANNC scope. Two absolute IRIs having the same path component and differing in the authority part refer to the same Manifestation. Their Item(s) is/are... well I don't know. Most probably not in the same domain as the resolver's authority at all.
> The only way it could be considered irrelevant is if there really is a guarantee of a unique Manifestation for a given path.
No. Of course we cannot nor should not "guarantee" a unique Manifestation as a result of the resolution. We * require * a unique Manifestation. It is the most we can do.
> In the Manifestation section, I do see
>
> " Therefore, different manifestations of the same Expression generated using different data formats correspond to different manifestations and will have different IRIs."
> I will assume that "different IRIs" here means "different global IRI references"
Correct.
> This doesn't address the case when different manifestations use the same data format, but, say, are prepared by different authors and so have different content.
Er. No. You seem to assume that a "data format" and a "label describing in short a data format" are the same thing. The Akoma Ntoso document I prepared with my markup and annotation and the Akoma Ntoso document with your markup and annotations, are different Manifestations, even though they are both in XML and both have ".akn" or ".xml" as their "data format" bit in their Manifestation-level IRI reference. That's why we need the Manifestation date and Manifestation source bits in the Manifestation-level IRI reference.
> There seems to be an implication that these authors will coordinate among themselves when they name their manifestations so that there are no name clashes. I don't see how it can be guaranteed there will never be such name clashes.
We do not guarantee avoidance of name clashes in the Manifestation sources. We could, of course, obtain that by requesting that the Manifestation source bit is the domain name of the source of the Manifestation. We discussed it and decide against it for practical reasons. We can of course revise that decision, but frankly, I do not see the point of fighting in advance against the situation in which two separate manifestation authors for the same expression (say, a national law of some country) happen to choose the same manifestation source identifier. If this is your fear, we can of course set up a global register of manifestation sources. But really I think this would be at the moment pointless, or at least premature.
> This is exactly the significance of the authority portion of the IRI. Since the dispensing of ownership of domains is handled by a central authority, this serves to distinguish between IRIs that have identical path components.
Nope. The authority portion of the Manifestation IRI is where the mapping to Item-level IRIs takes place. Since all Item-level IRIs of the same Manifestation are byte-by-byte identical, the exact nature or location of the resolver has no relevance in the organization of the resolution process.
> The last sentence of that paragraph
> "Any party interested in absolute IRIs for Akoma Ntoso are required to produce their own resolution engine and use its protocol and authority for the purpose."
> seems to be phrased quite poorly. "Any party interested in absolute IRIs for Akoma Ntoso" - so if I simply want to use an absolute IRI to refer to an Akoma Ntoso thing, then I have to build a resolution engine? This can't be what you mean to say.
You may be right here. Of course I want to say that if you simply want to use an absolute IRI to refer to an Akoma Ntoso thing, then you have to use any resolution engine that adheres to the rules here. We will change the sentence.
> It really comes across as very dismissive of anyone who would care to use (or is even interested in!) the absolute IRIs in an external application. Yet you have agreed that only the absolute IRI is the true identifier.
I have agreed that the absolute IRI is the true identifier of the Item. But the Item is not relevant in the ANNC. A manifestation is referred to by a Manifestation-level IRI reference. An expression is referred to by an Expression-level IRI reference, and a work is referred to by a Work-level IRI reference.
I hope my answers can satisfy you now. Still open to further discussions.
Ciao
Fabio
--
>
>
> Tara
>
> On 6/5/15 6:40 AM, Fabio Vitali wrote:
>> Dear Tara,
>>
>> thank you for your comments. Please find here a short discussion of the points you raise. I will definitely welcome your opinion on my answers.
>>
>> On 04/giu/2015, at 18:52, Tara Athan
>> <taraathan@gmail.com>
>> wrote:
>>
>>
>>> The document states that International Resource Identifier as per RFC 3987 (http://tools.ietf.org/html/rfc398
>>> ) is a normative reference. Therefore the document should use the terminology introduced in RFC 3987 according to the definitions provided in RFC 3987.
>>>
>>> In Section 4.2, the following is stated:
>>> "According to the authoritative source RFC 3986, all
>>> http://
>>> IRI references are divided into absolute IRI and relative IRI references. "
>>>
>>> One must be careful here. RFC 3986 defines URIs, not IRIs.
>>>
>>> The precise quote from RFC 3987 is
>>>
>>> "IRI reference: Denotes the common usage of an Internationalized Resource Identifier. An IRI reference may be absolute or relative. However, the "IRI" that results from such a reference only includes absolute IRIs; any relative IRI references are resolved to their absolute form. "
>>>
>>> Based on this definition, there are two cases of IRI references:
>>> 1. an IRI reference that is absolute (also called an absolute IRI, or simply IRI)
>>> 2. an IRI reference that is a relative (also called a relative IRI reference)
>>> RFC 3987 only uses the phrase "absolute IRI" once, for emphasis. Elsewhere, it simply uses IRI.
>>>
>>> This is supported by the ABNF rule from 3987
>>>
>>> IRI-reference = IRI / irelative-ref
>>>
>>> In contrast, Akoma Ntoso Naming Convention states
>>>
>>> "In the following we will call all IRI
>>> references as simply IRI (they are all references, after all), and distinguish between absolute IRIs, global IRIs and local IRIs."
>>>
>>> RFC 3986 uses the terminology "absolute-path reference"/ "relative-path reference" for a relative URI reference that starts/doesn't start with a slash.
>>>
>>> RFC 3987 doesn't use the term "absolute-path reference" directly, but does reuse the ABNF rule:
>>> ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
>>>
>>>
>>> I appreciate the motivation for the introduction of the modifiers "global" and "local" to distinguish this partition of IRI references, as the reuse of "absolute" and "relative" to refer to paths may lead to confusion relative to absolute IRIs and relative IRI references. Further these terms are not used in RFC 3987, only in RFC 3986, so technically an absolute-path reference is a URI reference, not an IRI reference.
>>>
>>> The main problem with the terminology of "global IRI" and "local IRI" is that these are not IRIs, they are IRI references, syntactically speaking.
>>> While the terms "IRI" and "IRI" reference are often (incorrectly) used interchangeably in informal usage, in an OASIS standard these terms should be used correctly, formally, and not interchangeably.
>>>
>>> Suggestions:
>>> 1. replace all occurrences of "global IRI" or "global IRI ref" with "global IRI reference"
>>> 2. replace all occurrences of "local IRI" or "local IRI ref" with "local IRI reference"
>>>
>> I appreciate and concur with this request. In origin we decided for readability purpose that "we will call all IRI references as simply IRI", but since your reading proves that this is actually a source of confusion rather than a simplification, we should definitely get rid of the ambiguity.
>>
>> Let me point out that, except for explanatory and introductory textual material, there is no room in the ANNC for IRIs and URIs. We only use IRI references.
>>
>> As for the subtle distinction between URI references and IRI references, as you point out the RFC3987 is somehow lacking in terminology, basing itself upon 3986. We never intended to use URI references, only IRI references, since our natural audience does not necessarily use Latin scripts. As such we strived to avoid using URI or URI references anywhere, and used IRI and IRI references instead. We stand by our choice of using for IRI references those terms and productions that have been used for URI references and that can be used for IRI references unchanged.
>>
>>
>>> There is an additional aspect to this whole IRI/IRI reference issue, that is somewhat obfuscated by the misuse of terminology described above. Using "IRI" to refer to what are actually IRI references hides the fact that there is still a missing piece of information that must be obtained from somewhere in order to resolve this "global IRI" to an actual IRI - the domain name (and port, if appropriate). The Akoma Ntoso XML schema guarantees that this additional information cannot be specified explicitly in the Akoma Ntoso document - there is no xml-base attribute, or any other component that serves this purpose, and all IRI references are required to be relative.
>>>
>> Correct.
>>
>>
>>> I am especially concerned about this statement
>>> "Any party interested in absolute IRIs for Akoma Ntoso are required to produce their own resolution engine and use its protocol and authority for the purpose."
>>> I suppose this may be a practical necessity, given that there can be no real guarantee that a particular domain name is always owned by the legal system. However, it does depart from the ideal of the Web - that (absolute) IRIs are the identifiers. I would like to see the motivations and ramifications (e.g. security concerns) of this decision discussed in detail in the Standard, as it is setting a very significant precedent.
>>>
>> I believe this is where our opinion start to differ. We do not see how this can be a departure from the ideal of the web. Absolute IRIs still are the identifiers. What we are discussing here is not identifiers. It's references.
>>
>> What we are saying is that legal and legislative documents never refer to physical documents somewhere on the web, but always to abstract ideas of documents, whose physical representations (i.e., files) abound in time, location, content AND ownership. This means that resolution is far from an occasional occurrence that can be avoided by specifying more metadata, but rather it is the fundamental mechanism through which the legal referencing mechanism works. We introduced and relied from the ground up on FRBR exactly for this reason. FRBR is VERY IMPORTANT for the Akoma Ntoso Naming Convention.
>>
>> In particular, you (almost) NEVER specify Item-level absolute IRIs within Akoma Ntoso documents (there are exceptions, but they are in fact exceptions, there is a special markup for them and they do not affect the ANNC). You only specify Work-level, Expression-level, and, in a few and very specific contexts, Manifestation-level IRI references.
>>
>> Resolution of a legal reference, given our FRBR setting, is therefore composed of two separate processes:
>> 1) given an (incomplete) Work-level or Expression-level IRI reference, the identification of the (complete) Manifestation-level IRI reference that best matches it. I call this the *completion* phase of the resolution.
>> 2) the identification of the absolute IRI of (one of) the physical files that embody the identified Manifestation. I call this the *mapping* part of the resolution.
>>
>> The Akoma Ntoso Naming Convention DOES NOT DISCUSS the mapping. An AN reference is completed into a Manifestation-level IRI reference. That's it. We do NOT deal with identifiers of physical files.
>>
>>
>>> For example, suppose I decide to publish something at http://athant.com/akn/ke/debaterecord/2011-06-10/main that is similar, but not identical, to the example at http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd01/part2-specs/examples/ke_Debate_Bungeni_2011-06-10.xml
>>> . Since this is my own domain, I am free to publish what I like there. But the path suggests that I am publishing a copy of the legal code with the identifier "/akn/ke/debaterecord/2011-06-10/main". This seems like a ripe opportunity for spoofing.
>>>
>> I believe this is the core of your objections, and it is were I disagree most strongly.
>>
>> AKoma Ntoso IS NOT INTERESTED in having direct resolution of IRI references to physical IRIs, so it does not (by design) guarantee correctness in the second process, which is a further resolution step which we cannot and do not want to control. This step is not part of the ANNC context, and this is the reason we write "Any party interested in absolute IRIs for Akoma Ntoso are required to produce their own resolution engine and use its protocol and authority for the purpose."
>>
>> Coming to your example, since "/akn/ke/debaterecord/2011-06-10/main" is NOT a Manifestation-level IRI reference (in fact, it looks like a Work-level reference) an Akoma Ntoso resolver will be able to provide you with a working Manifestation-level IRI reference, say,
>> "/akn/ke/debaterecord/2011-06-10/main/eng@/klr.xml"
>> . This is where the scope of the Akoma Ntoso Naming Convention ends. In this example, klr may refer to Kenya Law Report, an entity entrusted by the Kenyan government to be the authoritative source for a specific manifestation of the work.
>>
>> Physical documents are identified by exactly ONE Item-level absolute IRI, web-like to the fullest. They are referred to by an open set of IRI references, here again very much web-like. Akoma Ntoso only specifies how these IRI references look like. It does NOT claim they are IRIs (except as a shorthand, and I already agreed we should get rid of this habit), and it is not interested in the final step of the resolution (Manifestation IRI reference -> Item-level absolute IRI).
>>
>> So what should we say of protocol, domain and port of the IRI references? That they will always the same as the base, whichever they might be. We are just saying that the reference you should find in an Akoma Ntoso document (that MAY omit the protocol being IRI references) MUST omit the protocol and also MUST omit domain and port, and rely on the corresponding ones of the base.
>>
>> I don't see how these specifications are not web-like.
>>
>>
>>> The above scenario contradicts the statement "This, in practice, means that protocol and authority are, in resolution, not contributing information, and are thus interchangeable.", which makes the assumption that the resource identified by the IRI having the given absolute path is the same as the official document. This is in fact the primary role of the "authority" component of an IRI - to establish a certain level of trust.
>>>
>> "Official document" is not a term we use. I do not have any idea of what an official document is. Surely this is not what legal references point to.
>>
>> This is among the finest and most delicate concepts that Akoma Ntoso deals with. Legal references are NOT to physical documents, neither official nor authoritative nor public nor private nor spoofing ones. They are references to abstract entities, that exist in a conceptual domain.
>>
>> In fact, quite often resolving to "official documents", whatever that might be, is the wrong choice. Suppose for instance that you have an act X, dated 2010. This act has been modified by act Y and act Z in 2012 and 2014, respectively. What has been modified? The physical file on the server of the Parliament of the country? Most probably not (hopefully not). The abstract idea of act X has been modified. Often this is purely virtual, i.e. no-one has taken the task of authoritatively updating the text of act X to reflect the changes introduced by act Y and act Z. Sometimes private actors do it, sometimes no-one does it. There is NO "official document" of the latest version of a modified act.
>>
>> So if you have a reference of, say,
>>
>> /akn/country/act/X (Work-level IRI reference),
>>
>> what is the best destination? Probably not the "official document", which possibly only the earliest version, i.e., it is an outdated version that is most likely not valid for your case... Possibly you must look at other sources of updated versions of the acts (we call them consolidated versions). They are often NON AUTHORITATIVE. Use them at your risk. There might exist NO authoritative consolidated version of the document you are looking for. Very easily.
>>
>> And in our case there are three different versions (original one, after modifications of Y, after modifications of Y and Z), with three different contents each of which matches your reference (there would be more if we were in a multi-language country such as the European Union). The only thing we can do is to find, in some fashion, the best expression for you (say, today's version in some language), obtaining
>>
>> /akn/country/act/X/language@ (expression-level IRI reference),
>>
>> which again says very little, because we could have multiple data formats and MOST IMPORTANTLY we could have multiple sources, some of which authoritative, other quite reliable, other irremediably bad. These are reflected in the next step of the completion, where surely the data format, and possibly the source, are identified, so you may obtain:
>>
>> /akn/country/act/X/language@/og.xml (manifestation-level IRI reference)
>>
>> where og may stand for "official gazette" or it could be the identifier of another, less authoritative source.
>>
>> This is where the scope of the Akoma Ntoso Naming Convention ends and where the control is left to the usual web mechanisms for resolution: you obtain a Manifestation-level IRI reference for your Work-level IRI reference. Since "it is a requirement of Akoma Ntoso that all existing FRBR items of a Manifestation be byte-per-byte identical to each other", we are not further interested in finding the "right" item, because they are out of scope for the ANNC.
>>
>> What we need now is a resolver that maps your Manifestation-level IRI reference into an Item-level absolute IRI, and then we're good. AND IT IS THIS LAST STEP where spoofing may occur, but this step is well outside the scope of the Naming Convention.
>>
>>
>>> My feeling is that these things that are called "global IRI" and "local IRI" should not even be considered IRI references, since there is no set method for resolving them, so they don't refer to any particular IRI.
>>>
>> THERE IS a method for resolving them. It is a STANDARD method for resolving IRI references: you look at the base and use the items from the base to fill in for the missing details.
>>
>> In fact, resolvers exist TODAY (e.g.,
>> http://akresolver.cs.unibo.it/
>> ) that do exactly this using nothing weirder that a plain old browser.
>>
>>
>>> These strings are in fact the identifiers in and of themselves.
>>>
>> They are not identifiers. They are references. The way you call them (references) and the way they call themselves (identifiers) are rather different and there is a resolution process in between. So they are NOT the same and cannot be. We do NOT allow document identifiers (i.e., IRIs) within Akoma Ntoso documents (with a few clearly marked exceptions), and only allow references (i.e., IRI references).
>>
>>
>>> They have a certain resemblance to IRIs/IRI references, which is a convenience for processing, but they do not satisfy the definition of an IRI syntactically nor do they match the concept of an IRI reference from a functional perspective, and so shouldn't be considered as either. Why not call them something else, e.g. "global aknID", "local aknID", to make this clear?
>>>
>>> Suggestions (preferred):
>>> 1'. replace all occurrences of "global IRI" or "global IRI ref" or "global IRI reference" with "global aknID", or something similar.
>>> 2'. replace all occurrences of "local IRI" or "local IRI ref" or "local IRI reference" with "local aknID", or something similar.
>>>
>> For what I said, I conclude that I object strongly to this suggestion and would rather keep the text as it is. I believe that our design and our systems are very much in line with the current web as it is now, and we call our references as IRI references because they are.
>>
>>
>>> A couple of minor clarification in 4.2
>>> 3. clarify that only IRIs in the http scheme start with
>>> "http://";
>>>
>>> " An absolute IRI starts with the string “
>>> http://”;
>>>
>>> should be
>>> "An absolute IRI in the http scheme starts with the string “
>>> http://”;
>> I agree with this correction.
>>
>>
>>> 4. There are in fact network-path references (RFC 3986) that start with "//" and include the authority but not the scheme.
>>> " A relative reference, on the other hand, has no indication of the scheme, no indication of the domain name, and may ..."
>>> should be
>>> " A relative reference, on the other hand, has no indication of the scheme, and may"
>>>
>> I agree with this correction.
>>
>>
>>> 5. Clarify that IRI references are independent of the resolution mechanism, but that the resolved IRIs are (highly) dependent on this mechanism
>>> "This makes all IRI references independent of the actual resolution mechanism, and allows for very flexible storage, access, and reference mechanisms. On the other hand, the resolved IRI is dependent on the resolution mechanism, which may supply the missing information from an arbitrary base IRI."
>>>
>> Let me repeat myself again here. The resolved absolute IRIs are NOT part of the Akoma Ntoso Naming Convention, which is only interested in the determination of the most appropriate Manifestation-level IRI reference obtainable given a different-level IRI reference within the ANNC.
>>
>> The final resolution (if you prefer, the ACTUAL resolution) takes place using standard web mechanisms for IRI references, including relying on the base for the provision of protocol, domain and port of the resolved IRI.
>>
>> It is web-like, it works, it does NOT break any ideal, mechanism, or tool of the Web.
>>
>>
>>> 6. Typos
>>> "In fact, this is a simplification of RFC 3986, that calls global IRI refs as “absolute path references” and local IRI refs as “relative path references”. "
>>> should be
>>> "In fact, this is a simplification of RFC 3986, that calls global IRI references as “absolute-path references” and local IRI refs as “relative-path references”."
>>>
>> I agree with this correction.
>>
>>
>>> 7. Don't use "ref" as a word.
>>>
>> I agree with this remark.
>>
>>
>>> 8. Proper attribution of IRI terminology to RFC 3987, and avoid usage of "absolute IRI reference", which does not appear anywhere in RFC 3987. Further, the scheme is irrelevant.
>>>
>>> "According to the authoritative source RFC 3986, all
>>> http://
>>> IRI references are divided into absolute IRI and relative IRI references."
>>> should be
>>> "According to the authoritative source RFC 3987, all IRI references are divided into absolute IRIs and relative IRI references."
>>>
>> I agree with this correction.
>>
>> Thank you for your constructive remarks, and if in the things I wrote here you find a way to further improve the text of the naming convention, please let us know.
>>
>> Best regards
>>
>> Fabio Vitali
>>
>> --
>>
>> Fabio Vitali The sage and the fool
>> Dept. of Informatics go to their graves
>> Univ. of Bologna ITALY alike in this respect:
>> phone: +39 051 2094872 both believe the sage to be a fool.
>> e-mail:
>> fabio@cs.unibo.it
>> Where, then, may wisdom be found?
>>
>> http://vitali.web.cs.unibo.it/
>> Qi, "Neither Yes nor No", The codeless code
>>
>>
>>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]