IRC log of tagmem on 2003-02-07

Timestamps are in UTC.

17:21:41 [Ian]
17:21:43 [Ian]
contentPresentation-26 : Separation of semantic and presentational markup, to the extent possible, is architecturally sound.
17:21:45 [DanC_jam]
DanC_jam has joined #tagmem
17:22:29 [Ian]
Action CL: Create a draft finding in this space. Deadline 3 March.
17:22:30 [Ian]
17:22:34 [Ian]
IRIEverywhere-27 : Should W3C specifications start promoting IRIs?
17:23:00 [Ian]
CL: There is movement here; Martin commented on CL / IJ draft.
17:24:13 [Ian]
CL: Interrelated with URIEquivalence. Decision there affects IRIEquivalenc.e
17:24:58 [Ian]
CL: I had a proposal, but discussion happening and consensus shifting.
17:25:39 [Ian]
Action CL: post document to www-tag, with notation that MD doesn't agree.
17:28:12 [Ian]
17:28:19 [Ian]
17:28:43 [Ian]
fragmentInXML-28 : Use of fragment identifiers in XML
17:28:47 [Ian]
xmlIDSemantics-32 : How should the problem of identifying ID semantics in XML languages be addressed in the absence of a DTD?
17:28:53 [Ian]
TB: I think they are related.
17:29:21 [Ian]
TB: If you are solving the ID problem, you need to also decide how to solve the frag id problem.
17:29:34 [timbl]
timbl has joined #tagmem
17:29:35 [Ian]
[Roll call: TB, CL, PC, RF, DO, DC, SW, TBL, IJ]
17:32:46 [Ian]
PC: I am willing to be owner of 32
17:33:08 [Ian]
17:33:18 [Ian]
binaryXML-30 : Standardize a "binary XML" format?
17:33:46 [Ian]
(for XML ID, see msg from CL to tag
17:34:04 [Ian]
CL: I wrote up stuff for TAG, processing input on it.
17:34:19 [Ian]
TB: Is there a sense that W3C should do something in this space?
17:34:32 [Ian]
CL: There are issues, e.g., streaming (been demonstrated).
17:34:47 [Ian]
CL: BIM is patent-encumbered.
17:37:02 [Ian]
TB: I am not favorable to W3C doing work in this area.
17:37:06 [Ian]
DC: We should publish what we've done.
17:38:09 [Ian]
Action CL: Write up this work on binary XML.
17:38:11 [Ian]
17:38:57 [Ian]
metadataInURI-31 : Should metadata (e.g., versioning information) be encoded in URIs?
17:39:10 [Ian]
Action SW: Draft finding for this one.
17:39:28 [Ian]
17:39:32 [Ian]
xmlProfiles-29 : When, whither and how to profile W3C specifications in the XML Family
17:39:47 [Ian]
PC: Henry Thompson asks what the TAG wants to happen.
17:40:03 [Ian]
PC: They are looking for more details than we have given them.
17:40:13 [Ian]
DC: Liam Quin has the ball on this; he has accepted this.
17:42:58 [Ian]
17:46:46 [Ian]
17:47:39 [Ian]
DC: I have some questions on how to compare URIs.
17:48:01 [Ian]
DC: I want to tell people that if they use strcmp that they can get the right answer.
17:50:21 [Ian]
TB: It's clear that strcmp won't produce a false positive, but may produce some false negatives, but that's ok for some apps.
17:51:37 [Ian]
TB: People feel that appropriate place for this material is RFC2396
17:52:00 [Ian]
Action TB: Send URI equiv draft finding to
17:52:33 [Ian]
Resolved: Accept deep linking finding.
17:52:49 [Ian]
17:53:01 [Ian]
Action IJ: Publish Deep Linking finding as accepted finding.
17:54:55 [Ian]
17:55:04 [Ian]
[DC slide presentation on URI equivalence]
18:04:33 [timbl]
Cliunets should only assume foo and foo/ are equive when redot occurs
18:04:35 [Ian]
DC: Redirection [Slide information hiding]
18:05:47 [Ian]
TBL: We should say here "Don't do this!" ; there's a high cost to reserved names here.
18:06:28 [Ian]
TB: robots.txt has problems; could have been done lots better.
18:06:34 [Chris]
Chris has joined #tagmem
18:06:48 [timbl]
We should actually look at a a technical solution to the robots.txt problem in future, and even think of transitioning
18:07:55 [Ian]
TB: Two things should happen:
18:08:01 [timbl]
q+ to say that we should actually look at a a technical solution to the robots.txt problem in future, and even think of transitioning
18:08:08 [Ian]
1) I should take several things from DC's slides and give a different takeaway message.
18:08:11 [Zakim]
Zakim has joined #tagmem
18:08:17 [timbl]
q+ to say that we should actually look at a a technical solution to the robots.txt problem in future, and even think of transitioning
18:08:30 [Ian]
TB 2): I think you should dress up your slides and publish it as a service to the world.
18:08:38 [Ian]
Action DC: Pretty up slides and publish.
18:09:32 [Ian]
TBL: You can look at 2 URIs some times and sometimes tell they are equivalent; you can never tell (just by looking at the URIs) that they are different.
18:10:03 [Ian]
18:10:10 [Ian]
Architecture Document
18:10:32 [timbl]
18:11:23 [Ian]
TBL (on robots.txt): If this is bad, should we invest time into asking some group to do it properly.
18:11:51 [Ian]
TBL: A generic hook for putting site metadata on a header.
18:12:09 [Ian]
RF: It's a design trade-off. Latency with every GET, or reserved space to look for information.
18:12:59 [Ian]
Action TBL: Write up a proposal for a new issue regarding generic metadata hooks (related to robots.txt).
18:13:01 [Ian]
18:13:04 [Ian]
Back to Arch Doc.
18:13:37 [Ian]
SW: I like the structure of the document; but I don't think this document tells me what the architecture of the Web is.
18:14:09 [Ian]
SW: Could talk more about people building on top of the platform that is the Web.
18:14:58 [Ian]
SW: I'd like a conceptual model to be presented up front.
18:15:08 [Ian]
SW: We get into good practice without establishing the model.
18:15:44 [Ian]
SW: I'd like the doc to be as short as possible, with links out to more info.
18:16:56 [Ian]
TBL: The style of the doc is close to what I think is reasonable. We spend a lot of time talking about nuggets, but have as a goal to produce an all-encompassing work. We should allow ourselves to produce a document that is uneven.
18:17:17 [Ian]
TBL: I think that we should assume that the reader knows a fair amount about the WEb.
18:17:37 [Ian]
TBL: We should use terms consistently, but we needn't be overly formal.
18:18:28 [Ian]
TBL: If we want to be formal, doing a mathematical ontology would be unbelievably useful, but I see that as something separate.
18:19:20 [Ian]
TBL: The document is morphing slowly; I don't know when to read it.
18:20:06 [Ian]
TBL: HTTPRange-14 has become a discussion between me and Roy. I think that if we come up with a consistent story, people will probably go along with that.
18:21:16 [Ian]
RF: I think we need to ensure that we are using the terms consistently.
18:24:25 [Ian]
TB: I think I would like the doc to be thin and consist of bald statements ("this is the way it is") with examples in the document.
18:24:53 [Ian]
TB: Whenever you need historical exegesis, good place for a finding.
18:25:25 [Ian]
TB: Still need to clear up principle v. constraint v. choice. Need to clean up or throw out.
18:25:35 [Ian]
TB: Pace has been unsatisfactory over last 4 months.
18:26:02 [Ian]
TB: I'm unlikely to use CVS; Happy to use Ian as a single point of editing.
18:26:36 [Ian]
CL: I'm getting more comfortable since I've started editing.
18:28:44 [Ian]
PC: I don't have many concerns right now. What is public perception of the document?
18:28:50 [Ian]
TB: We haven't had much feedback.
18:29:06 [Ian]
PC: I don't know whether we're doing enough to get people to comment on this document.
18:30:49 [Ian]
PC: Do we really expect to go to last call in 5 months? We have to have real targets about what we want in the document at last call.
18:31:50 [Ian]
PC: For last call, this document has to describe the Web as it is today. I'm not convinced we have to describe the Web of the future in v 1.0.
18:34:00 [Ian]
TBL: We need to make clear in status of this document that we don't expect to be done in v 1.0.
18:34:18 [Ian]
PC: We need to agree to the scope of v 1.0.
18:35:05 [Ian]
CL: We need to make clear whether we are following, e.g., the Process Doc model or model of a technical spec.
18:35:26 [Ian]
RF: I'd like to add more scenarios and more background.
18:36:02 [Ian]
RF: I think we need to do a better job explaining the framework.
18:36:44 [Ian]
RF: I can deal with people using different terms; but not happy with people using same terms differently.
18:37:02 [Ian]
RF: I would prefer to have an agreed upon TAG / attribute mechanism so I can edit in place.
18:37:36 [Ian]
Action IJ: Explain how to edit in place.
18:38:25 [Ian]
DO: To me, a lot of things are missing about the Web architecture:
18:38:32 [Ian]
- We don't say what we mean by an architecture.
18:39:55 [Ian]
There are things like data, connectors, etc. in RF's thesis. Those are useful; I'd like to be able to relate WSA to Web Arch via this framework.l
18:41:00 [Ian]
DO: E.g., definition of "agent" used in arch doc caused criticism of term in WSA community.
18:41:00 [DanC_jam]
(odd... I see those things [constraints, etc.] in our arch doc.)
18:41:38 [Ian]
DO: Clearer glossary terms
18:42:39 [Ian]
PC to DO: Should arch doc be limited to Web today or Web with Web services?
18:42:44 [Ian]
DO: Let's discuss later.
18:42:53 [Ian]
DO: We need treatment in other areas than URIs.
18:43:00 [Ian]
DO: E.g., architecture of XML.
18:44:20 [Ian]
DC: I'm invested in arch doc up to 2.1. Swimming in rest of 2. Not much opinion of rest of doc.
18:44:28 [Ian]
DC: Process has been sort of ok for me.
18:44:44 [Ian]
DC: I don't understand why there are pent up comments; people should send text.
18:45:18 [Ian]
DC: On the challenge of brevity v. understandability; I see that what we are doing is having some effect.
18:45:44 [Ian]
DC: Probably ok with terse prose and elaboration elsewhere.
18:46:16 [Ian]
DC: In many cases, I find that rationale is economic, not logical. That's ok.
18:46:43 [Ian]
DC: There are a few cases where the principle is something I agree with, but not expressed exactly correctly.
18:46:57 [Ian]
DC: Often problematic in quantifiers. I owe text on this.
18:47:03 [Ian]
DC: Diagrams would be nic.e
18:47:14 [Ian]
DC: I'd like to see more discussion of the text that we've got.
18:47:40 [Ian]
RF: I'd like to get all of us writing into the document. Fine to have 10x the text, and then reduce it from there.
18:48:24 [Ian]
19:03:43 [Ian]
19:03:56 [Ian]
[On the Interactions section.]
19:04:03 [Ian]
RF: I have affinity for this section, but not as it stands.
19:04:44 [Ian]
19:04:57 [Ian]
Discusssion of terms.
19:08:08 [Ian]
URI ----Identifies---> Resource
19:08:25 [Ian]
Resource ----RepresentedBy----> bag of bits + media type
19:09:39 [Ian]
Representation includes bits and other metadata about the representation
19:10:37 [Ian]
RF: I note that Content-Length is used inconsistently.
19:12:30 [Ian]
TBL: Web Architecture doesn't tell you whether two resources are the same.
19:13:46 [Ian]
TBL: Difference between URI-equivalence and HTTP-equivalence.
19:15:03 [Ian]
TB: Both DC and TBL are right. We know that moby and moby.html are quite possibly the same thing in real life. But the Web arch doesn't have the notion of "same in real life" built in.
19:15:27 [Ian]
TB: We need to ack the fact that (1) this occurs in real life but that (2) just by looking at the URI there's no way to tell.
19:17:28 [Ian]
DC: I don't agree to TBL's constraint that only one URI identifies a resource and no way to talk about URI-equivalence.
19:18:09 [Ian]
TB: Web arch doesn't have a built-in relationship "isEquivalentTo" that applies to multiple URIs.
19:22:16 [Ian]
TBL: We agree on URIs (as set of bits) and Representations (as set of bits) since we have machines that can work on them. We don't have agreement in the abstract realm (Resources).
19:22:39 [Ian]
TBL: You can't claim that "resource" is a shared term.
19:24:16 [Ian]
[Disagreement about identity relationship.]
19:25:30 [Ian]
DC: To me, the URI spec is a worldwide agreement for a convention for making up identifiers and how they take on meaning through use.
19:25:42 [Ian]
DC: You share your understanding of their meaning by servicing GET requests.
19:30:12 [Ian]
[Discussion of range of "Resource"]
19:31:37 [Ian]
[Question: Can you use ANY URI to talk about ANY Resource?]
19:34:06 [Ian]
TBL: My expectation is for consistent information about a resource from one representation to the next. What keeps the Web working is that the form of identity is that representations for a resource continue to convey the same information.
19:38:26 [Ian]
PC: I think DC's original diagram should be included in arch doc.
19:39:26 [Ian]
PC: I still haven't heard pros and cons of TBL's model v. DC's model.
19:42:36 [Ian]
TBL: Problem with DC model is that when you have a URI for a real book, you can get two inconsistent DC:Creator assertions for the same URI (either email address of person who created page about the book v. Herman Melville).
19:43:43 [Ian]
[RF writes "urn:isbn:2389768" on the white board]
19:44:48 [Ian]
TBL: Following the specs can lead to an inconsistency.
19:45:34 [Ian]
RF: DC:Creator specifically refers to the creator of the representation.
19:46:07 [Ian]
RF: DC:Author is another identifiers
19:47:17 [Ian]
[DC moves to reopen this issue for a variety of reasons.]
19:47:46 [Ian]
DC: I think an arch doc that addresses knowledge representation is a valuable asset; I would like to spend my time there.
19:47:54 [Ian]
DO: I'd prefer to not reopen this issue.
19:48:16 [Ian]
PC: I'd rather not reopen.
19:48:45 [Ian]
PC: The second diagram may be a refinement of the first diagram (DC's) but we can do that later.
19:49:27 [Ian]
TBL: I'm not trying to go down path of KR, just trying to use terms precisely.
19:49:51 [Ian]
TBL: Without getting the diagram nailed down, we will not have a precise definition of these terms.
19:50:25 [Ian]
RF: WSA does need to verify that HTTP URIs don't always refer to documents.
19:51:52 [Ian]
For - 4, Against - 3, Abstain 1
19:52:13 [DanC_jam]
RESOLVED to reopen it.
19:52:38 [Ian]
RF: I don't think we will have a document in July unless we resolve this issue.
19:52:51 [Ian]
TBL: I have a hard time contributing to the document without clear term usage.
19:53:06 [Ian]
SW: I think we have to agree to foundational model and put it up front in document.
19:54:40 [Ian]
<pause to meeting plan>
19:54:54 [Ian]
Assignments for tech plenary:
19:55:21 [Ian]
Three issues, overview of arch doc, relationship of TAG to community.
19:55:35 [Ian]
CL: issue 32
19:56:24 [Ian]
PC: Issue 8
19:57:21 [Ian]
NW (not confirmed: 29
19:58:31 [Ian]
DC: Walk-through of arch doc.
19:58:58 [Ian]
TBL: Role of the TAG (10 mins).
19:59:49 [Ian]
Action PC: Report this plan to the tech plenary planning committee.
20:00:15 [Ian]
20:00:18 [Ian]
Meeting planning
20:00:27 [Ian]
[May? July? Oct/Nov?]
20:05:36 [Ian]
Resolved: 21 May (afternoon), 22 May, 23 May (morning) in Budapest.
20:05:52 [Ian]
Action IJ: Talk to admin folks to schedule this.
20:07:37 [Ian]
TBL: Please note that this overlaps with the W3C track, and so there may be some absences.
20:08:13 [Ian]
Action PC: Talk to WWW 2003 conf organizers (Ivan?) about registration fees and also TAG session.
20:09:10 [Ian]
Proposed 21,22,23 in YVR.
20:09:18 [Ian]
RF: I prefer Bristol.
20:09:36 [Ian]
DC: Likely regrets for 21 July.
20:10:00 [Ian]
[Issue of not flying during weekend.]
20:10:11 [Ian]
Proposed 21 afternoon,22,23 in YVR.
20:10:40 [Ian]
Resolved: 21 July (afternoon), 22, 23 in Vancouver.
20:10:46 [Ian]
20:12:38 [Ian]
14-15 Nov in Japan.
20:20:08 [Ian]
[Strong expectation, but not resolved.]
20:20:21 [Ian]
Action IJ: Talk to Nov AC meeting planners to see if 14-15 ok for TAG meeting.
20:20:50 [Ian]
20:20:54 [Ian]
Arch Doc scheduling.
20:21:03 [Ian]
Does CR period make sense?
20:21:15 [Ian]
SW: I think we should see, e.g., whether we help two WGs get to Rec.
20:23:13 [Ian]
20:39:11 [Zakim]
Zakim has left #tagmem
22:27:23 [Ian]
22:28:18 [Ian]
22:28:26 [Ian]
Chris Lilley stuff
22:29:54 [DanC_jam]
DanC_jam has joined #tagmem
22:31:41 [Ian]
<we review changes CL made in source of arch doc>
22:34:34 [Ian]
" 1. An Internet Media Type, which may include optional or mandatory parameters"
22:34:44 [Ian]
TB: I disagree with this. There are other parameters.
22:35:36 [Ian]
TB: Does internet media type include charset, etc.?
22:35:44 [Ian]
DC: I'd feel better with citation of the relevant spec.
22:36:03 [Ian]
RF: The whole first paragraph is bogus.
22:38:06 [Ian]
TB: Do we consider that representation includes just data, or just media type header, or all headers....?
22:38:33 [Ian]
From HTTP 1.1 spec:
22:38:39 [Ian]
22:38:39 [Ian]
An entity included with a response that is subject to content
22:38:39 [Ian]
negotiation, as described in section 12. There may exist multiple
22:38:39 [Ian]
representations associated with a particular response status."
22:39:31 [Ian]
RF: Representation is data and metadata.
22:40:35 [Ian]
TB: Representation = body + one or more headers that are included in the message response (but not part of body).
22:41:06 [Ian]
TBL: Mime type is particularly important since determines how to interpret bag of bits.
22:41:22 [Chris]
Chris has joined #tagmem
22:41:44 [Chris]
the representation is payload in the message
22:42:18 [Chris]
current text assumes a one way server to client delivery, need to widen to include sending *to* the server
22:43:12 [Chris]
metadata is more stuff than just the media type
22:43:20 [Chris]
eg content transfer encoding
22:43:35 [Chris]
draw attention to the media type as a fundamental part of the metadata
22:43:54 [Chris]
metadata in the body (eg rdf in html) is not being considered here
22:44:06 [Chris]
.... or is it (html meta http-equiv stuff)
22:44:20 [Chris]
rrsagent, pointer?
22:44:20 [RRSAgent]
22:45:22 [Ian]
TBL: Some parts of an HTTP header are not part of a representation
22:45:27 [Ian]
DC: E.g., Date.
22:46:02 [Ian]
CL: Slicing half of the headers as being in or out of the representation is a pain.
22:46:07 [Ian]
DC: That's part of life as we know it.
22:46:36 [Ian]
DC: "Not modified' means previous representation not good. But the transfer metadata can change.
22:46:50 [Ian]
s/not good/not modified.
22:48:46 [Ian]
TB: I think I agree with CL. From the perspective of agents, I have access to all headers and status. In principle and practice, this is information that is available to the agent. It doesn't seem to me to be harmful to dispatch processing based on, e.g., transfer encoding.
22:49:01 [Ian]
TB: Furthermore, other headers will be invented.
22:49:15 [Ian]
TB: I propose that we assert that the representation is data + all metadata.
22:49:41 [Ian]
[DO distinguishes metadata about content from metadata about the message.]
22:49:44 [Chris]
DO message metadata and format metadata
22:49:57 [Ian]
DO: I would like to distinguish message from representation in the arch doc.
22:52:06 [Ian]
RF: Representation defined this way so that it has the same meaning in both PUT and POST situations.
22:52:20 [Ian]
RF: You don't create messages on a server; you create representations.
22:52:53 [Chris]
messages contain representations and other headerstuff; representatios contain formats and headerstuff
22:53:46 [Chris]
message metadata and representation metadata
22:53:48 [Ian]
RF: We know that that it was a mistake in HTTP to not be able to distinguish msg metadata from representaiton data.
22:53:58 [Ian]
RF: We would fix that in the next protocol spec.
22:54:06 [Chris]
protocol-ng should explicitly differentiate there two
22:54:11 [Chris]
these two
22:56:09 [Ian]
RF proposal:
22:56:22 [Ian]
- Resource rep consists of metadata about the representation and data for the representatoin.
22:56:30 [TBray]
TBray has joined #tagmem
22:56:47 [Ian]
DO: We need to talk about msgs in the arch doc.
22:56:49 [Chris]
message consists of message metadata and representation.
22:57:05 [Chris]
in http headers the two types of metadata are unfortunately comingled
22:57:09 [TBray]
What I think we agreed on (just joined IRC so pardon if redundant)
22:57:46 [TBray]
A representation includes some data, e.g.. arbitrary bag of bits, plus some metadata about the data
22:58:35 [Chris]
rrsagent, pointer?
22:58:35 [RRSAgent]
22:58:37 [DanC_jam]
where is "representation data" used, Roy?
22:58:49 [TBray]
In the case of HTTP, some of the headers are part of the representation, e.g. Media-type and Content-length; others are not, e.g. Date and Content-encoding
23:00:09 [Chris]
add diagrams to document
23:00:18 [Chris]
diagrams reuse existig concepts
23:00:25 [Ian]
PC: I'd like to have a diagram, reuse existing definitions, link to authoritative specs that define these terms.
23:01:08 [Ian]
DC: "entity" "entity body".
23:01:17 [Ian]
RF: "representation data" comes from RF PhD.
23:02:40 [Ian]
23:03:53 [DanC_jam]
I asked whether we intend to import "body" from the MIME spec ; the question went unanswered. Lilley said he had sufficient advice on the matter to produce another draft. Nothing was decided.
23:05:45 [Chris]
add +xml to processing model section
23:05:58 [Ian]
TB: In section on processing model, include info about following mime type, support for 3203, xml namespaces....
23:08:30 [Chris]
these are properties arising from using xml
23:09:12 [Chris]
xml as a constraint
23:10:10 [Ian]
PC: Main reason to use XML is neutral format for interoperability
23:10:11 [Chris]
xml gives interop
23:10:15 [Chris]
major reason
23:12:33 [Ian]
RF: Application-independent at the parser level.
23:14:36 [Ian]
CL: Facilitates composability.
23:14:40 [Chris]
facilitates composability
23:15:55 [Chris]
xml for interop
23:15:57 [DaveO]
DaveO has joined #tagmem
23:16:00 [Chris]
namespaces withour schemas
23:16:00 [Ian]
PC: namespaces w/o schemas help define parts of xml doc.
23:16:05 [Chris]
namespaces with schemas
23:16:09 [Ian]
PC: When you add schemas, you get a more powerful definition language.
23:16:45 [DaveO]
for definition purposes, from wsd document: A Message is the basic unit of communication between a Web Service and a Client; data to be communicated to or from a Web Service as a single logical transmission.]
23:17:11 [Chris]
well knoown namespaces confer meaning
23:23:36 [Ian]
CL: I try to present things as a continuum.
23:24:02 [Ian]
TBL: I like "presentation", I don't like abstract/concrete.
23:25:21 [Chris]
tim wants me to avoid the term semantics here - great!
23:27:27 [Ian]
CL: Need to clarify use of term "interaction": network interaction or human-computer interaction.
23:27:40 [Ian]
TB: "Protocol" is heavily overloaded.
23:29:13 [Ian]
RF: There are multiple architectures of the Web - at the agent level, at the UI level, etc...
23:32:22 [TBray]
23:45:34 [Ian]
CHris's draft:
23:45:35 [Ian]
23:46:25 [Ian]
23:46:51 [Ian]
TB comments review
23:47:09 [Ian]
23:49:07 [Ian]
TB: Lose distinctions.
23:49:22 [Ian]
IJ: I find three distinctions useful: best practice, design choices, and axioms ("it is this way")
23:50:46 [Ian]
IJ: It's one thing to design the doc with these things explicitly in mind; another to label them explicitly.
23:51:02 [Ian]
TB: I'm not convinced that it's valuable to create a taxonomy and label things in the document according to this taxonomy.
23:52:04 [Ian]
RF: Useful to distinguish goal, way to get to that goal, and a property established by making that decision.
23:52:56 [Ian]
RF: Allows other communities to see that, by relaxing a particular constraint, they may lose a particular goal.
23:53:20 [Ian]
TBL: I don't find property/goal distinction useful.
23:55:32 [Ian]
RF: Constraint is "The only identifiers in the Web are URIs."
23:55:38 [Ian]
RF: But arch doc is not expressed that way.
23:55:59 [Ian]
TB: however, it's useful to instruct in terms of best practice.
23:56:11 [DanC_jam]
i.e. "if you're pointing from one thing to another, use URIs". Yes, that's a constraint.